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Chapter  1 


INTBODDCTION 

1.  1  Jhe  Problem 

1.1.  1  Introduction  of  Complex  Data  Base.  Management  Soft; 
ware 

The  aata  base  approach  for  the  storage,  maintenance,  and 
retrieval  of  data  is  becoming  a  popular  approach  to  the 
problem  of  organizing  data  using  a  computer.  A  1979  publi- 
cation by  B.  L.  Nolan  indicated  that  over  60  percent  of  the 
total  number  of  data  processing  installations  are  committed 
to  the  data  base  approach  (NOLA79)  for  the  organization, 
storage,  maintenance,  and  retrieval  of  data.  The  tradition- 
al and  data  base  approaches  to  data  management  differ  in 
that  traditional  data  management  methods  organize  data  in 
support  of  a  specific  service  of  an  organization,  introduc- 
ing unnecessary  replication  of  data,  whereas,  the  data  base 
approach  maintains  data  as  a  resource  for  the  entire  organi- 
zation offering  the  opportunities  for  reduction  of  data  re- 
dundancy and  the  reduction  of  maintenance,  integration,  and 
retrieval  costs.  Sophisticated  data  base  management  soft- 
ware,  known  as  data  base   management  systems  (DBFISs)  ,   have 
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been  written  to  support  the  data  base.  Although  several 
different  classifications  of  the  loqical  data  organization 
for  data  bases  exist  {e.g.,  hierarchical,  network,  and  rela- 
tional) ,  the  majority  of  functioning  DBMSs  are  based  on  the 
network  model  (01LE78).  Network  DBMSs  are  considered  effi- 
cient to  operate  if  the  data  base  is  orqanized  properly,  but 
data  bases  organized  according  to  the  network  model  are  com- 
plicated to  design.  This  complexity  demands  a  broad  spec- 
trum of  expertise  from  those  responsible  for  data  base  de- 
sign. Thus,  tools  to  automate  or  partially  automate  this 
design  process  would  be  very  helpful  to  those  faced  with  the 
task  of  automating  the  design  of  a  data  base  structure  ac- 
cording to  the  network  model. 

1.1.2  D a ta  Base  Des ign  Expertise 

The  central  responsibility  for  data  base  design  is  the 
data  base  administrator  (DBA).  As  indicated  by  a  well  expe- 
rienced data  base  consultant  and  frequently  published  au- 
thor, Ronald  Ross,  the  expectations  of  the  DBA  are  over- 
whelming. 

"The  typical  corporate  DBA  finds  himself  trapped 
on  every  side  by  a  set  of  expectations  totally  out 
of  line  with  reality.  On  the  one  hand,  DP  manage- 
ment expects  that  the  DBA  be  thoroughly  proficient 
in  the  technology  of  the  corporate  DBMS,  so  that 
database  systems  run  smoothly  and  efficiently.  .  . 
Yet  at  the  same  time,  application  and  business 
analysts  (as  well  as  end  users)  demand  that  the 
DBA  be  so  knowledgeable  about  detailed  business 
operations  that  all  the  endless  subtleties  of  "do- 
ing business"  can  be  taken  into  account  when  cre- 
ating the  database  design,  .  .  .  still  more  expec- 
tations crowd  in  on  the  DBA.  Realizing  that  a 
crucial   measure   of   any   applications' s   success 
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(whether  database  or  not)  is  the  ability  to  expand 
and  evolve  over  time — and  that  maintenance  over- 
head is  a  primary  obstacle  to  this  goal — the  DBA 
is  expected  to  create  database  designs  havinq  in- 
herent stability.  .  .  .  Translated,  this  means 
that  the  DBA  must  also  be  an  expert  on  the  practi- 
cal application  of  normalization  for  the  design  of 
large-scale  data  resources.  .  .  .  Finally,  there 
is  one      last   source      of   expectations.  For    those 

corporations  that  have  implemented  a  data  adminis- 
tration function,  the  DBA  is  expected  to  adhere 
to,  and  promulgate,  the  data  element  (and  other) 
standards    which   that    group    produces.  "  (R0SS82) 

In  the  likely  event  that  the  DBA  cannot  completely  ful- 
fill all  the  above  expectations,  a  number  of  problems  may 
arise.  According  to  Jan  Bumberger  of  TSI,  International, 
the   problems   are   not   new   ones.      He   states, 

"The  list  of  problems  is  a  familiar  one:  D3HSs 
being  used  as  an  access  method,  DAs  unable  to  get 
a  real  handle  on  element  standardization,  poor 
database  designs,  high  subsequent  maintenance 
costs.  The  results  is  increasing  user  and  manage- 
ment disenchantment  with  the  costs  and  promised- 
but-not-delivered  benefits  of  data  base  technolo- 
gy."    (EOSS82) 

These  problems  can  have  significant  impacts  on  the  produc- 
tivity of  an  organization.  It  is  imperative  to  develop 
tools  which  reduce  the  expertise  which  must  be  available  to 
an  organization  designing  a  data  base  and  to  move  the  design 
process  from  the  art  that  it  is  currently  to  a  scientific 
methodologically   based    process. 
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1.1.3  Data  Base  Develo£ment  Aids  and  their  Shortcomings 

Three  of  the  most  widely  used  data  base  development 
aids  currently  available  to  data  base  designers  are  1)  the 
data  dictionary,  2)  the  normal  forms  introduced  through 
relational  data  base  theory,  and  3)  data  base  development 
methodologies. 

1.1.3.1  Data  Dictionary 

Due  to  the  sizable  volume  to  data  necessary  to  design, 
implement,  and  maintain  large  computerized  systems,  the  con- 
cept of  the  data  dictionaries  emerged.  Although  there  does 
not  exist  a  single  definition  for  a  data  dictionary,  the 
following  is  one  that  most  would  find  acceptable. 

"A  DD/D  [Data  Dictionary/Directory]  is  a  central- 
ized repository  of  information  about  data  descrip- 
tions such  as  meaning,  relationships  to  other 
data,  responsibility,  origin,  usage  and  format. 
It  is  a  basic  tool  within  the  data  base  environ- 
ment that  assists  company  management,  data  base 
administrators,  systems  analysts,  and  applications 
programmers  in  effectively  planning,  controlling, 
and  evaluating  the  collection,  storage  and  use  of 
the  data  resource."  (UHK073) 

Although  data  dictionaries  are  useful  data  base  develop- 
ment aids,  they  are  not  without  problems.  Data  dictionaries 
are  designed  primarily  as  maintenance  aids  and  not  data  base 
development  aids  (BOSS82)  .  Furthermore,  in  instances  when 
data  dictionaries  are  designed  to  function  as  pre-implemen- 
tation  utilities  they  ".   .   .   are  concerned  with  efficient 
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physical  data  storage  and  access.  They  don't  address  them- 
selves to  the  problem  of  generating  an  appropriate,  com- 
plete,   accurate,    and   long   lasting   schema.  "  (TSIC78) 

1.1.3.2    Normalization 

The  theory  of  relational  data  base  normalization,  as  in- 
troduced by  Edgar  Codd  of  IBM  Corporation  (CODD70)  ,  provides 
useful  criteria  for  grouping  data  elements  so  as  to  reduce 
data  redundancy  and  limit  data  maintenance  anomalies.  (A 
more  precise  definition  of  normalization  is  provided  in 
Chapter  3.  )  Normalization  has  proven  to  be  a  useful  design 
aid  no  matter  which  logical  data  organization  model  is  being 
used. 

The  foremost  problem  with  normalization  is  that  tradi- 
tional normalization  technigues  (i.e.,  manual  technigues) 
are  complex,  cumbersome,  and  error-prone.  Although  a 
synthesis  algorithm  has  been  derived  to  meet  the  criteria  of 
normalization  [BEEN76)  ,  in  only  one  known  case  has  this  pro- 
cess been  incorporated  as  a  design  aid  in  an  automated  data 
base   development    process    (ROSS82)  . 

1.  1.3.3   Data    Base   Development    Methodologies 

To  provide  a  more  systematic  approach  to  data  base  de- 
sign the  academic  (TSIC78,  HOLI79,CfiEN77)  ,  consultant 
(YOUB79,MUER80)  ,  and  corporate  (ATRE80,MCEL79)  communities 
have   established      data    base      design   methodologies.  A   data 


base  design  methodology  eclectically   derived  from  the  above 
sources  appears  in  Exhibit  1.  1. 

{1)  Determine  user  requirements 

(2)  Document    data   element   attributes  and    their 
inter-relationships 

(3)  Create   normalized    records 

(4)  Establish   inter-record   relationships 

(5)  Create    a   conceptual  schema 

(6)  Transform   the   conceptual   schema   into   a 
physical   model 

(7)  Convert    the    physical    model   into  data 
definition  statements 

Exhibit    1.1 

While  working  as  a  consultant  for  Performance  Development 
Corporation,  Ronald  Ross  supported  data  base  methodoloqies 
similar  to  the  one  in  Exhibit  1.1  in  corporations  nation- 
wide. Through  his  experience  he  found  several  major  areas 
of   concern. 

"First,  the  projects  tended  to  become  overwhelming 
simply  by  the  sheer  volume  of  documentation  pro- 
duced. The  tasks  of  monitoring  standards,  admin- 
istering revisions,  and  producinq  reports  often 
became  major  stumbling  blocks  to  success.  ...  A 
second  problem  was  that  no  hard  and  fast  method 
existed        for        translating  user        requirements 

("services")  into  a  stable  nonredundant  database 
architecture.  Almost  inevitably,  it  seemed,  head- 
strong and  performance-oriented  DBAs  ended  up  do- 
ing their  own  physical  designs--which  may  or  may 
not  have  either  matched  the  users'  requirements  or 
constituted      a   reliable      model      of   his      business." 

(R0SS82) 

These  concerns   are  addressed  directly  by  the   research  de- 
scribed in  this  thesis. 
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1.2  Current   Relevant    Research 

In  a  search  of  the  literature  only  one  automated  inte- 
grated approach  to  data  base  desiqn  was  discovered.  The 
system,  still  under  development,  is  known  as  FACETS 
(ROSS82)  .  Ronald  Ross,  formerly  of  Performance  Development 
Corporation,  was  seriously  considering  automation  of  the 
data  base  design  process  as  early  as  the  mid-1970s.  By 
1981,  Ross  had  made  marketable  the  initial  system  components 
of  what  will  likely  become  an  integrated  system  for  automa- 
tion of  the  conceptual  data  base  design  process.  FACETS  is 
described  by  the  manager  of  Data  Management  Products  for 
TSI,  International,  Jan  Rumberger,  as  "representing  a  major 
evolutionary  step  .  .  .  that  will  ultimately  encourage  bet- 
ter— and  more  creative — results  with  database  development 
than   ever   before   possible."    (ROSS82) 

The   information      required   for      the   use      of    FACETS      car.    be 
classified   in   three   categories. 

"Defining  the  business  context  of  the  data  base 
project,  primarily  (but  not  exclusively)  to  answer 
'strategic'  questions  of  scoping,  planning  and 
higher-level   data    organization.    ... 

Defining  the  individual  requirements  that  the  fu- 
ture database  project  must  satisfy.  These  re- 
quirements are  called  'services,'  and  roughly 
equate  to  inputs  and  outputs  the  end-users  need 
within   the    new  system. 


Developing  a  logical  architecture  for  the  database 
system.  In  contrast  to  the  'local  requirements' 
of  the  previous  area,  the  logical  database  archi- 
tecture represents  a  'global*  statement  about  in- 
tegrated  data  organization."    (R0SS82) 
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In    order   to      create   and  maintain   the     above  data,      FACETS 
supports  three    major   processes: 

1)  The  entry  and  inspection  of  "Service  Local 
Views"  to  represent  user  requirements  and  ob- 
tain  dependencies   about    data   elements. 

2)  The  "Relational  Generator"  module  to  provide  an 
automation  of  the  normalization  process  based 
on  information  provided  by  "Service  Local 
Views". 

3)  The  "Database  Project  Dictionary"  to  enter, 
maintain,  cross-reference,  query,  etc.  informa- 
tion relevant  to  the  data  base  development  pro- 
ject.    (MCCH83) 

Thus  the  FACETS  system  terminates  in  the  desiqn  process  with 
the  fifth  step,  create  a  conceptual  schema  (see  Exhibit 
1.1).  FACETS  is  said  to  be  generalized  in  that  it  is  de- 
signed to  collect  all  the  data,  data  descriptions,  and  data 
relationships  required  in  steps  six  and  seven  of  Exhibit 
1.1.  Since  steps  six  and  seven  require  knowledge  of  the 
specific  tarqet  DBMS,  FACETS  requests  or  creates  data  not 
required  for   a    specific   DBMS. 

1. 3   The  Solution 


In  contrast  with  FACETS,  the  system  described  in  this  pa- 
per, known  as  DB_GEN,  has  been  designed  not  only  to  be  a 
useful  design  aid,  but  specifically  to  map  the  logical  enti- 
ties of  a  user's  data  base  schema  into  IDHS  data  definition 
language  statements  (PERH77)  .  That  is  to  say,  this  tool, 
DB_GEN,  aids  the  designer  through  all  sever,  steps  of  the  de- 
sign process  (see  Exhibit  1.1),  but  aids  in  desiqn  steps  six 
and  seven   only    for   one    specific    DBMS,    IDMS. 


The  major  objectives  of  this  research  are: 

1)  to  organize  and  simplify  the  data  base  design 
process  through  applied  data  base  development 
aids  and 

2)  to  carry  the  design  process  beyond  logical  data 
base  design  by  transforming  a  conceptual  view 
of  the  data  base  into  CODASYI  data  description 
source  statements  (specifically  those  reguired 
by  the  Integrated  Data  Management  System  mar- 
keted by  Culinet  (PEBR77)). 

A  generalized  system  such  as  FACETS  may  fail  to  reguest,  or 
at  least  poorly  represents,  all  necessary  data  for  specific 
DBPISs.  Thus,  through  selection  of  a  specific  DBMS  the  au- 
thor feels  the  objectives  of  this  research  can  be  more 
clearly  stated  and  addressed. 

The  research  objectives  of  this  implemention  were  met  us- 
ing a  single  menu-driven  interactive  PL1/IDMS  program  called 
DB_GEN.  The  data  flow  diagram,  depicting  the  flow  of  con- 
trol and  data  within  DB_GEN  is  presented  in  Exhibit  1.2. 


CONTROL    AND    DATA    FLOW    DIAGRAM    FOR    DB^GEN 


FUNCTIONAL  S 
NON- FUNCTIONAL 
DEPENDENCIES 


Major  entities 
DATA  BASE,  F.ECORD 
DATA  ELEMENT,  and  SET 


SYMBOL 


o 


IDMS  SCHEMA 
STATEMENTS 


MEANING 


PROCESS 


SOURCE  OF  INFORMATION 


TEMPORARY  REPOSITORY 
OF  DATA 


DATA  FLOW 


Exhibit  1.2 
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As  illustrated  by   the   control  and   data   flow  diagram   in 
Exhibit  1.2,   the   initial  inputs  into  the  system  are  func- 
tional and  nonfunctional  dependencies.    A  functional  depen- 
dency (FD)  exists  when  a  given  data  element  value  is  unique- 
ly identified  by  the  value  (or  set  of  values)  of  one  or  more 
other  data  elements.    For  example,   a  functional  dependency 
exists  between  data  elements   X  and  Y  if  for  any  value  of  l 
there  is  at  most  one  value  of   Y  (written  'X  >  T')-    A  non- 
functional dependency  (NFD)  exists  when  a  given  data  element 
value  is   not  uniquely   identified  by  the   value  (or   set  of 
values)  of  one  or  more  other  data  elements.    For  example,  a 
nonfunctional  dependency  exists  between   data  elements  R  and 
S  if  for  any  value  of  E  there  is  zero,   one,   or  more  values 
of  s  (written  "R  »  S")  .   once  functional  and  nonfunctional 
dependencies  are   collected,   the  data  base  about   the  data 
base  schema  (i.e.,   a  meta   data  base),   is  initialized  (see 
process  one  of   Exhibit  1.2).    All  meta   data  base  entities 
(DATA  BASE,  DATA  ELEMENT,  RECORD,  and  SET)  are  customized  in 
process  two   of  Exhibit  1.2   to  meet  user   requirements  with 
respect  to  IDMS  specifications.     DB_GEN  was  desiqned  under 
the  assumption  that   the  data  base  desiqner   (and  the  reader 
of  this   report)   has  a  qood   workinq  knowledge  of   the  IDMS 
generalized  data  base  management  system  (PERR77).   Following 
customization  of  data   base  entities,   process  three   of  the 
control  and  data  flow  diaqram  transforms  the  data  base  enti- 
ties into  IDMS  data   definition  languaqe  statements  accepta- 
ble to  the  IDMS  schema  compiler  shown  in  process  four. 
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1.4  Guide  to  this  PaEer 

In  order  to  familiarize  the  reader  with  menu  perusals. 
Chapter  2,  Desiqn  Overview,  illustrates  the  user  interaction 
formats  which  are  consistent  throuqhout  the  entire  implemen- 
tation. Additional  menus  indicate  how  entities  that  are 
stored  in  the  meta  data  base  are  updated  and  what  types  of 
interactions  are  made  when  conflicts  between  entity  attri- 
butes exist.  once  menu  perusals  are  introduced,  an  outline 
of  primary  activities  is  used  as  an  overview  of  the  various 
system  features. 

A  useful  generation  of  entities  requires  a  clear  under- 
standing of  user  needs.  Chapter  3,  Bernstein's  Algorithm 
and  User  Hequirements,  discusses  the  transformation  of  user 
requirements  into  functional  and  nonfunctional  dependencies 
and  describes  how  Bernstein's  alqorithm  uses  these  dependen- 
cies to  create  a  relational  schema. 

Chapter  4,  Data  Base  Initialization  and  Interpretation, 
provides  a  description  of  how  maior  meta  data  base  entities 
are  established  from  data  element  dependencies.  Functional 
dependencies,  throuqh  the  use  of  Bernstein's  alqorithm,  qen- 
erate  data  elements  and  records.  In  addition  to  the  qenera- 
tion  of  data  elements  and  records,  functional  dependencies 
also  establish  1-to-1  inter-record  relationships.  Nonfunc- 
tional dependencies  are  modified  to  represent  owner  and  mem- 
ber records  and  once  modified  the  respective  1-to-many  rela- 
tionships are  generated. 


12  - 


Chapter  5,  Data  Base  Customization,  describes  the  inter- 
action between  the  data  base  designer  and  the  system  in  or- 
der to  resolve  issues  about  the  data  in  the  meta  data  base 
that  are  mechanically  unresolvable.  Special  emphasis  is 
made  to  default  as  many  DBMS  software  parameters  as  possible 
to  minimize  the  need  for  customization.  In  situations  where 
the  efficiency  of  the  data  base  operation  is  the  only  con- 
cern, parameter  selection  is  made  without  the  ability  for 
the  DBA  to  make  modifications.  However,  the  DBA  is  given 
the  ability  to  modify  all  parameters  that  involve  a  correct 
representation  of  user  needs.  All  modifications  are  care- 
fully scrutinized  for  potential  conflicts  and  if  such  con- 
flicts are  found  the  system  responds  with  helpful  advice. 
To  insure  the  integrity  of  the  meta  data  base,  all  propaga- 
tional  changes  are  carefully  updated. 

Chapter  6  describes  the  process  of  creating  an  operation- 
al schema.  Once  meta  data  base  entities  are  customized  a 
transformation  must  be  made  from  the  augmented  conceptual 
view  to  the  IDM3  data  definition  statements.  Although  this 
module  consists  of  mostly  a  reformatting  task,  CODASYL  re- 
strictions, relationship  interpretations,  and  pointer  as- 
signments introduce  interesting  transformations  and  algor- 
ithms . 

Chapter  7  summarizes  the  contributions  of  this  research 
and  concludes  with  a  discussion  about  future  supportive  re- 
search. 
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Chapter    2 
DESIGN    OVERVIEW 


The  major  subsystems  of  DB_GEN  are  highliqhted  in  this 
chapter  and  covered  in  detail  in  later  chapters.  Addition- 
ally, a  case  study  is  introduced  in  this  chapter  and  used 
throughout  this  paper  as  a  tool  to  clarify  the  use  of  this 
system   by      the   data      base   designer.  Followed   by      the   case 

study  introduction,  several  sample  menu  traversals  throuqh 
DB_GEN  are  conducted  to  inform  the  reader  of  how  this  system 
is   used. 

2.  1    I mplementation   Description 

2.1.1    DB^GEN    Conceptual   Schema  and    Block   Diagram 

The  prevalent  tool  of  data  base  practitioners  to  under- 
stand and  describe  their  data  base  requirements  better  is  a 
conceptual  schema  (e.g.,  see  Exhibit  2.1).  Rectanqles  of  a 
conceptual  schema  represent  data  base  entities  containing 
data  elements  that  are  bound  by  a  unique  identifier.  The 
arrows  between  entities  represent  relationships  reguired  by 
user    policy.  A    double-headed    arrow   indicates      a    1-to-many 

relationship,  whereas,  a  single-headed  arrow  represents  a 
1-to-1    relationship.         Ironically,      this  implementation   uses 
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the  IDHS  network  DBMS  to  maintain  data  about  user  ID.1S  data 
base  schemas.  Therefore,  the  conceptual  schema  describing 
the  data  used  by  DB_GEN  (see  Exhibit  2.1)  is  a  data  base 
schema  representing  data  base  entities  and  the  relationships 
between  those  entities  (i.e.,  a  meta  data  base  schema). 
This  meta  data  base  is  representative  of  what  has  been  tra- 
ditionally  called  a   data   dictionary. 
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The  block  diagram  of  processes  in  Exhibit.  2.2  illustrates 
the  six  major  modules  and  significant  sub-modules  of  DB_GEN. 
These  modules  are  used  by  the  data  base  designer  during  the 
development    of   a    user's   data    base   schema. 
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2.1.2  Infiut,    Out£Ut,    and   Processes   of   DB_GEN 

The  data  base  designer  enters  DB_GEN  in  the  DB_ENTRY  mod- 
ule (see  Exhibit  2.2)  where  a  selection  of  a  user's  data 
base  schema  is  made  from  those  that  are  present  in  the  DATA 
BASE   entity    (see  Exhibit    2.1).  (Note:        Throughout   the  re- 

mainder of  this  section,  when  there  is  a  reference  to  an 
"entity"  or  "relationship"  occurrence,  refer  to  Exhibit  2.1, 
and  when  there  is  a  reference  to  a  "module"  occurrence,  re- 
fer to    Exhibit    2.  2). 

All  services  for  development  of  the  user's  data  base 
schema  are  then  presented  through  a  primary  menu  in  the 
LEVEL_2   module. 

The  first  service  provided  in  the  development  of  a  user's 
data  base  schema  is  to  initialize  the  major  entities  of  that 
schema   using      the   DB_INIT    module.  Functional   dependencies 

(FDs)  and  nonfunctional  dependencies  (NFDs)  representing 
user  requirements  are  stored  in  the  DEPENDENCIES  entity  and 
are  linked  to  an  instance  of  the  data  base  entity  by  the 
INITIALIZED-BY  relationship.  Once  functional  and  nonfunc- 
tional dependencies  are  present  in  the  meta  data  base, 
DATA- ELEMENT,  HECOBD,  and  SET  entities  may  be  created.  Fur- 
thermore, the  association  between  DATA-ELEMENT  and  RECORD  is 
established  by  the  POPUL ATED-WITH  and  GEOIJPED-IN  relation- 
ships. (The  two  relationships,  POPULATED-WITH  and 
GROOPED-IN,      form   an   H-to-N   relationship    (i.e.,      a   bi-direc- 
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tional  1-to-many  relationship) .  This  M-to-N  structure,  also 
known  as  a  complex  relationship,  cannot  be  directly  imple- 
mented in  IDAS.  Subsequent  chapters  discuss  how  complex  re- 
lationships like  this  one  are  simplified.)  In  order  to 
avoid  redundant  record  names  in  the  SET  entity  of  Exhibit 
2.  1,  the  OWNER-OF  and  BEMBER-OF  relationships  establish  a 
SET'S  owner  and  member  records.  (The  two  relationships, 
OWNER-OF  and  MEMBEB-OF,  constitute  a  multiple  relationship. 
Multiple  relationships  allow  different  relationships  with 
the  same  owner  to  point  to  different  member  record  instances 
within  the  same  member  record.)  All  entities  created  durinq 
data  base  initialization,  i.e.,  DATA-ELEMENT,  RECORD,  and 
SET  entities,  are  licked  respectively  to  the  DATA  BASE  enti- 
ty using  DEFINED-BY,  DI VIDED-INTO,  and  LINKED-BY  relation- 
ships . 

Following  the  creation  of  these  entities,  customization 
of  record  attributes  are  conducted  using  the  DB_CUST  module. 
The  customization  module  has  the  capabilities  to  modify  all 
entities,  entity  attributes,  and  relationships  created 
through  data  base  initialization.  In  addition  to  these  ca- 
pabilities, sub-elements  of  a  data  element  can  be  estab- 
lished using  the  CONCATEN ATED-BY  relationship.  (This  situ- 
ation, where  a  single  data  element  points  to  one  or  more 
sub-elements,  is  referred  to  as  an  Lii  relationship--a  link 
JL)    with  the   same    owner  and   member   record    (i)  .) 
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The  final  step  in  the  data  base  development  process  is  to 
create  the  data  definition  statements  representing  the 
user's  data  base  from  information  stored  in  the  meta  data 
base.  In  situations  where  complex  relationships  exist,  this 
module,  SCHEMA -CREATE,  may  create  new  RECORD  and  SET  in- 
stances. Otherwise,  this  module  only  retrieves  data  from 
the  meta  data  base  for  reformatting  into  compilable  IDAS 
data   definition   languaqe   statements. 

Any  time  during  the  data  base  development  process  the 
PRINT-DATA  module  may  be  used  to  print  or  display  informa- 
tion about  any  or  all  data  base  entities  in  the  meta  data 
base. 

2.  2  Case   Study,   Introduction 

In  order  to  aid  the  reader  of  this  work  a  simple  case 
study  of  the  Wampum  Brokerage  company  is  now  introduced. 
Although  this  case  study  is  restricted  to  two  outputs,  ef- 
forts have  been  made  to  ensure  the  inclusion  of  some  of  the 
most  difficult  data  base  design  and  implementation  problems 
(e.g.,  M-to-N  relationships,  data  relevant  to  two  or  more 
existing  records  (i.e.,  intersection  data),  1-to-1  relation- 
ships with  no  inverse,  and  the  potential  for  second  and 
third    normal   form   violations) .  Requirements   for    this   case 

study    are   altered   intermittently   in      order   to   emphasize   spe- 
cific  situations. 
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Exhibits  2.3  and  2.4  are  examples  of  two  Wampum  Brokerage 
output  requirements.  Although  this  case  study  is  limited  in 
scope,  existing  brokerage  houses  would  have  access  to  simi- 
lar displays/documents.  The  "stock  activity"  display  in  Ex- 
hibit 2.3  would  be  useful  when  news  broke  on  any  specific 
stock  {e.g.,  a  stock  split,  extreme  quarterly  earninqs  vari- 
ation, merger  or  take  over,  bankruptcy,  etc.).  The  broker 
would  want  to  have  the  latest  changes  in  stock  price  guotes 
and  volume  as  well  as  the  deqree  to  which  clientele  are  af- 
fected and  perhaps  a  list  of  those  clients  that  are  affected 
most.  This  display  would  also  be  used  when  clients  make 
queries  concerning  a  specific  stock  and  for  the  broker  to 
receive  updates  on  how  successful  previous  recommendations 
concerning  a  stock  have  been.  The  "client  activity"  display 
(see  Exhibit  2.4)  furnishes  the  broker  with  necessary  client 
demographic  information  showing  both  composite  and  detailed 
data.  This  would  be  useful  when  providing  financial  advice 
to  a  client. 
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***       STOCK    ACTIVITY    *** 


STOCK    NAME:       INTERNATIONAL    BUSINESS    MACHINES 

STOCK    ABBREVIATION:       IBM 

HOST    RECENT    QUOTE:       140    1/4 

MOST    RECENT    VOLUME:        1,824,000 

LAST    UPDATED:       12-01-83  10:24:13 

TOTAL    CLIENTAL    STOCKS:       650 

GAIN/LOSS    PERCENTAGE    WHEN    RECOMMENDED:       +13.37 


CLIENT 
ID  NAME 


021 
613 
419 
414 
812 


JOE    SLY 
TYCOON    MARY 
BAGS    MOONIE 
BULL   FRANCIS 
T    HOWELL    III 


PERCENT    OF 
QUANTITY       TOTAL    INVESTMENT 


200 
150 
100 
100 
100 


100 

12 

2 

80 

50 


PHONE 

555-8000 
555-6350 
555-6354 
555-0549 
555-2152 


Exhibit    2.3 


***   CLIENT  ACTIVITY  *** 

CLIENT  NAME:   BAGS  MOONIE 

CLIENT  ID:   411 

EMPLOYER:       KANSAS    STATE    UNIVERSITY 

ANNUAL    SALARY:       20000 

PHONE:         555-6354 

TOTAL    INVESTMENT:        16,200.00 

CURRENT   WORTH:       18,525.00 

GAIN/LOSS     PERCENTAGE:       +14.35 

STOCK    TRANS      BROKER  NO.  CURRENT         7.    GAIN 

ABRV      DATE         RECMND       PRICE         PUR       AMOUNT  WORTH  /LOSS 


IBM 


080  180 

YES 

90.00 

50 

4500.00 

100283 

NO 

150.00 

50 

7500.00 

7012.50       +55.83 
7012.50      -    6.50 


100       12000.00       14025.00      +16.875 


MCI         060182       YES  42.00       100  4200.00         6000.00       +42.86 

100         4200.00         6000.00       +42.86 


Exhibit    2.4 
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2.3   Using    DB_GEN 

2-3.1   Formats   for   DB_GEN    Interaction 

The  system  has  been  desiqned  to  be  user-friendly.  It 
provides  information  necessary  to  make  user  decisions  and 
aid  the  user  in  inputting  information.  User  responses  are 
consistent  throughout  the  entire  system--a  menu  number  and, 
optionally,  a  menu  entry.  Any  time  a  blank  entry  is  qiven 
in  response  to  a  menu  display,  the  system  responds  with  the 
general   instructions   in   Exhibit    2.5. 


***    GENERAL    INSTRUCTIONS 

*** 

|             TWO 

FOBHATS    CAN    BE    USED    — 

1             FORMAT    1:             <MENU_8UHBER> 

I             ==> 

THIS    WILL    PROVIDE    DETAILED    INSTRUCTIONS    FOR 

ENTERING    THE    RESPECTIVE 

INFORMATION 

I             FORMAT    2;               <MENU_NUMBER> 

<MENU_ 

ENTRY> 

1             =  =  > 

THE    DETAIL    INSTRUCTION 

STEP    Ii 

SKIPPED 

BY 

ADDING    THE    MENU    ENTRY 

E.G.  , 

1       STOCK_ 

DATA_ 

BASE       ] 

1           PRESS   enter    to   continue 

Exhibit  2.5 

As  a  user  becomes  familiar  with  the  system,  intermediate 
menus  can  be  skipped  by  giving  the  appropriate  menu  number 
and  menu  entry.  A  novice  user  of  the  system  will  find  that 
the  system  provides  adequate  guidance  for  its  use. 
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2.3.2   Data    Base   EniEIzz2S_M2£J 

Upon  entering  DB_G2N,  the  user  must  make  a  selection  from 
the  list  of  existinq  user  data  base  schema  nanes  or  create  a 
new  user  data  base  schema  (see  Exhibit  2.6).  Exhibit  2.6 
illustrates  the  selection  of  menu  number  one;  the  response 
of   this  request   is  shown   in   Exhibit    2.1k. 


I__ 


**    DATA    BASE    ENTRY    »* 

1)  CREATE    DATA    EASE 

2)  OPTION-DB 

3)  BOND-DB 
X)  EXIT 

MAKE    SELECTION    ===> 
1 


Exhibit    2.6 


**  CREATE  NEW  DATA  EASE  ** 

1 )  DATA  BASE  NAME: 

2)  DATA  BASE  ADMINISTRATOR: 
X)   EXIT 

Istock   data  base 


Exhibit  2.  7A 


**  CREATE  NEW  DATA  BASE  ** 

1)  DATA    BASE    NAME:       STOCK-DATA-BASE 

2)  DATA    BASE    ADMINISTRATOR: 
X)       EXIT 


Exhibit    2.71 
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The  naae  of  the  user's  data  base  schema  is  supplied  in  Ex- 
hibit. 2.7a  by  entering  menu  number  one  followed  by  the  menu 
entry  "stock  data  base."  Note  that  data  base  name  could 
have  been  supplied  from  Exhibit  2.fc  and  the  display  in  2.7a 
would  have  been  bypassed.  DB_GEH  is  already  preparing  for  a 
clean  schema  compile  by  altering  the  data  base  name  entered 
in  Exhibit  2. 7A  into  an  acceptable  IDMS  data  base  name  by 
removing  blanks  and  substituting  hyphens  (see  Exhibit  2.7B). 
These  flexibilities  and  interpretations  are  consistent  but 
limited.  One  must  be  careful  to  provide  user  friendliness 
as   well  as   data   integrity. 

2.3.3  SEilaie.   Considerations 

Care  has  also  been  taken  to  allow  for  changes  in  all  en- 
tity names  (i.e.,  data  base,  data  element,  record,  and  set 
names).  Exhibit  2.8  illustrates  a  change  of  the  data  base 
name. 
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**  CREATE  NEK  DATA  BASE  ** 

1)  DATA    BASE    NAHE:       STOCK-DATA-BASE 

2)  DATA    BASE    ADMINISTBATOB : 
X)       EXIT 

1    stock   db 


***    CEEATE    NEW    DATA    BASE    *** 

1)  DATA    BASE    NAME:       STOCK-DB 

2)  DATA    BASE    ADBINISTRATOB : 
X)       EXIT 


Exhibit  2.8 
DB-GEN  has  been  written  to  thorouqhly,  yet  efficiently, 
search  all  areas  where  chanqe  is  required  and  establish  the 
necessary  associations  between  entities  where  chanqe  propa- 
gates. For  example,  one  data  element  may  be  in  several  re- 
cords, be  a  candidate  key  for  several  other  data  elements, 
be  part  of  a  concatenated  key,  and/or  be  used  as  a  sort  or 
hashinq  field.  All  references  to  this  entity  attribute  are 
properly   modified   by   the  system. 
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2.3.1  Primary.   Menu   of   Services — LEVEL  2 

Upon   entering   a   data   base,      a    primary   menu   of    services   is 
provided    (see   Exhibit    2.9). 


DATA-BASE:       STOCK_DB 
**    PRIMARY       MENU    ** 


1)  DATA  BASE  INITIALIZATIOH 

2)  DATA  ELEMENT  UPDATE 

3)  RECORD  UPDATE 

4)  SET  UPDATE 

5)  DATA  BASE  UPDATE 

6)  PRINT  DATA 

7)  CREATE  SCHEMA 
X)  EXIT 

=  =  > 

2 


Exhibit    2.9 
The   primary      menu   of   services       (see   Exhibit   2.9)         serves   to 
quide    the    data   base   desiqner    through   the   design   process   of   a 
user's   data   base  schema.      This    Exhibit   is    used   to   support   an 
overview   of  this   implementation. 

2.3.4.  1    Data    Base    Initialization--DB_IN.IT 

Selection  one  (i.e.,  DB_INIT  module)  utilizes  a  very  lim- 
ited input  of  user  requirements  and  Bernstein's  Alqorithm  to 
perform  a  data  base  genesis.  Functional  dependencies  are 
used  to  create  data  elements  and  normalized  records.  The 
third  main  ingredient,  sets,  is  provided  through  nonfunc- 
tional  dependencies.      A   close   study   of   the   application's   re- 


26   - 


quirements        described        in        terms  of        functional        and 

non_f unctional   dependencies      provides   a     skeletal   form     upon 
which    to   build  the  user's   data    base   schema. 

2.3.4.2   Data    Base   Cus t omization-- DB_CU5T 

The  next  four  selections  from  the  primary  menu  are  used 
to  customize  the  entites  of  the  user's  data  base  schema. 
Actually,  enough  power  exists  in  these  four  modules  to  cre- 
ate the  data  base  schema  without  the  use  of  the  DB_INIT  mod- 
ule. As  data  element,  record,  set,  and  data  base  modifica- 
tions are  made,  there  is  constant  monitoring  for  conflicts. 
Conflicts  are  answered  with  an  error  message  followed  by  ad- 
vice. For  example,  if  one  selects  a  non-existent  record  to 
be  a  set  member,  the  error  message  and  assistance  of  Exhibit 
2.  10   appears. 


I  ******************************************************  ti:)r 

IRECDRD    SELECTED    AS    A    SET    MEMBER    DOES    NOT    EXIST  — USE    MENU 
| ********************************************************* 


**    SELECT    SET    MEMB2R    ** 


1)  STOCK 

2)  CLIENT 

3)  STK_CLNT 

4)  STK_CLNT_TXN 

5)  EMPLR 
X)  EXIT 


Exhibit    2. 10 
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This  list  of  records  (see  Exhibit  2.10)  can  then  be  used  to 
select  the  set  member;  the  assumption  is  that  the  user  in- 
correctly spelled  the  record  name. 

2.3.1*.  3  Printing  of  Data  Sage  £nf  orma£i2fiz:-,P!INT_DATA 

Selection  six  from  the  primary  menu  allows  the  user  to 
view  the  leta  data  base  data  in  a  composite  form  either  via 
display  or  hardcopy  by  using  the  menu  in  Exhibit  2.11. 


***  PBINT  DATA  BASE  INFORMATION  *** 

1)  DATA  ELEMENT  DISPLAY 

2)  DATA  ELEMENT  HARDCOPY 

3)  RECORD  DISPLAY 
<*)  RECORD  HARDCOPY 

5)  SET  DISPLAY 

6)  SET  HARDCOPY 

7)  ALL  THE  ABOVE 
X)  EXIT 


Exhibit    2.11 

2.3.4.4    Schema   Creation-=SCHEiJA_CBEAIE 

The  final  selection  of  the  primary  menu  (see  Exhibit  2.9) 
assures  an  initial  check  for  missing  data,  displays  minor 
errors,  and  then  makes  the  conversion  to  an  operational  data 
base  schema.  Because  the  previous  steps  carefully  scruti- 
nize attributes  of  major  entities,  the  user  should  not  be 
faced   with   many   changes   in   this   final    step. 
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2.3.5  Continued   Use   of    DB_GEH 

The  data  base  schema  is  now  ready  to  be  generated  for  ap- 
plication use.  Any  future  changes  due  to  forgotten  or 
changed  user  requirements  can  easily  be  made  throuqh  the  en- 
tity  customization  modules  followed  by  a  regeneration   of  the 

schema. 

To  provide  a  clearer  understanding  of  the  scope  of  this 
research,  this  chapter.  Design  Overview,  highlighted  the  ma- 
-jor  services  provided  by  DB_GEN  with  respect  to  the  data  ard 
modules  used  to  perform  these  services.  The  following  chap- 
ter, Bernstein's  Algorithm  and  User  Requirements,  begins  the 
process  of  discussing  the  major  parts  of  this  research  in 
detail. 
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Chapter    3 

BERNSTEIN'S    ALGORITHM 

AND 

USER    REQUIREMENTS 

In  a  1976  publication,  "Synthesizing  Third  Normal  Form 
Relations  from  Functional  Dependencies",  Phillip  Bernstein 
proved  that  a  normalized  relational  schema  can  be  synthes- 
ized "from  a  given  set  of  functional  relationships" 
(BERN76).  However,  it  is  not  clear  how  a  "given  set  of 
functional  relationships"  is  derived.  This  chapter  discuss- 
es the  translation  of  user  requirements  into  functional  and 
nonfunctional  dependencies  and  the  use  of  these  dependencies 
in   Bernstein's   algorithm. 

3.  1   DecomEOSition  fie t hod   for    Schema   fiprmalization 

Normalization  is  an  integral  part  of  nearly  all  data  base 
design  technigues  (CODD70,CODD72,C0DD7<3) .  Normalization  in- 
volves a  study  of  data  that  an  organization  uses  in  the  re- 
lationships and  dependencies  among  that  data.  The  purpose 
of  normalization  is  to  aqgregate  data  items  into  groups  in 
which  the  group  represents,  if  possible,  only  one  entity  of 
concern  to  the  user.  The  output  of  normalization  is  a  set 
of   data   table      definitions   which   is   organized      to   limit   data 
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base  redundancy,  thus  simplifying  data  maintenance  services 
and  enhancinq  data  base  integrity.  The  three  steps  of  nor- 
malization nay  best  be  defined  by  one  of  Codd's  colleagues, 
William  Kent. 

"FIRST  NORMAL  FORM:  A  relation  is  in  first  normal 
form  if  none  of  its  domains  has  elements  which 
are  themselves   sets. 

SECOND  NORMAL  FORM:  A  relation  in  first  normal 
form  is  in  second  normal  form  if  every  attribute 
in  the  complement  of  a  candidate  key  is  fully 
functionally   dependent   on   that    candidate   key. 

THIRD  NORMAL  FORM:  A  relation  in  second  normal 
form  is  in  third  normal  form  if  every  attribute  in 
the  complement  of  a  candidate  key  is  nontransi- 
tively   dependent   on   that   candidate  key. "  (KENT73) 

Codd's  method  involves  starting  with  one  relation  and  suc- 
cessfully decomposing  it  into  smaller  relations  until  all 
relations  adhere  to  the  above  normalization  criteria.  It  is 
possible  in  this  decomposition  approach  to  normalization  to 
create  a  system  which  no  longer  represents  all  the  FDs  in 
the  original  system  of  FDs.  Sfhen  this  occurs  the  user  loses 
the  possibility  of  referencing  some  of  the  information  from 
the   data  base   that   is   a  part    of   the   enterprise's   data. 

3. 2   Synthesis   Method    for   Schema    Normalization 

Phillip  Bernstein's  research  has  revealed  that  by  using 
FDs,  third  normal  form  relations  can  be  synthesized  using  an 
algorithm.  The  synthesis  technigue  for  use  in  normalization 
has  been  shown  to  be  much  more  rigorous  and  consistent  than 
the  original  decomposition  method.  All  FDs  provided  by  the 
designer  are  guaranteed  to  be  represented  in  the  schema  gen- 
erated  by   this   synthesis   method.      The   algorithm   follows. 
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"ALGORITHM  1 


(Eliminate  extraneous  attributes.)  Let  P  be 
the  qiven  set  of  FDs.  Eliminate  extraneous 
attributes  from  the  left  side  of  each  FD  in  F, 
producing  the  set  G.  An  attribute  is  extrane- 
ous if  its  elimination  does  not  alter  the  clo- 
sure of  the  set  of  FDs. 


(Find  covering.)   Find  a  nonredundant  covering 
H  of  G. 


3.  (Partition.)  Partition  H  into  groups  such 
that  all  of  the  FDs  in  each  group  have  identi- 
cal left  sides. 


(Merge  equivalent  keys.)  For  each  pair  of 
groups,  say  H1  and  112,  with  left  sides  X  and 
Y,  respectively,  merge  H1  and  H2  together  if 
there  is  a  bijection  X  < — >  Y  in  H*. 


(Construct  relations.)  For  each  group,  con- 
struct a  relation  consisting  of  all  the  attri- 
butes appearing  in  that  group.  Each  set  of 
attributes  that  appears  on  the  left  side  of 
any  FD  in  the  group  is   a  key  of  the  relation. 

(Step  1  guarantees  that  no  such  set  contains 
any  extra  attributes.)  All  keys  found  by  this 
algorithm  are  called  synthesized.  The  set  of 
constructed  relations  constitutes  a  schema  for 
the  given  set  of  FDs."  (BERN7fc) 


Exhibit  3.  1 

This   synthesis   technique   is   used   by   DB_GEN    as    the   method   for 
normalization   of   the   data   base   records. 

3. 3   translation    of   User    Beguirejngnts    into   FDs 

To    understand      better    how    Bernstein  establishes     FDs   from 
known    requirements,      we      re-examine   Exhibits    2.3    and      2.4   of 
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the  Wampum  Brokerage  case  study.  output  examples  are  quite 
useful  but  fall  short  of  the  rigor  reguired  to  adequately 
describe  the  underlying  policies  of  an  organization.  A 
starting  point  for  describing  entities  is  the  introduction 
of  a  unique  identifier  in  the  form  of  a  functional  dependen- 
cy for  each  data  element  appearing  on  the  output  examples. 
To  provide  further  semantic  value  to  the  functional  depen- 
dencies in  Exhibit  3.3,  consider  the  list  of  standard  abbre- 
viations (see  Exhibit  3.2). 


ABBREVIATION 

= 

ABRV 

PHONE 

■ 

PH 

AHOUNT 

= 

AMT 

PRICE 

= 

PRC 

ANNUAL 

= 

ANUL 

QUANTITY 

= 

QUAH 

BROKER 

= 

BRKR 

QUOTE 

= 

QUT 

CLIENT 

= 

CLNT 

RECENT 

= 

RCNT 

CURRENT 

= 

CUR 

RECOMMEND 

= 

RECMD 

DATE 

= 

DTE 

SALARY 

= 

SLRY 

EHPLOYER 

= 

EMPLR 

STOCK 

= 

STK 

GAIN_LOSS 

* 

GN_LS 

TOTAL 

■ 

TOT 

IDENTIFICATION 

= 

ID 

TRANSACTION 

= 

TXN 

INVESTMENT 

= 

INVST 

UPDATE 

= 

UPDTE 

NUMBER 

= 

NUM 

VOLUME 

= 

VOL 

PERCENTAGE 

PRCNT 

Exhibit    3.2 

WORTH 

— 

WRTH 

STK_NAME 

STK_ABRV 
STK_ABRV,CLNT_ID 

EKPLR_NAHE 
CLNT    ID 


>  STK_ABRV,RCNT_QUT, 
RCNT_VOL,STK_LAST_ UPDTE, 
TOT_A*T_WHEN_UPDTE, 
TOT_NUK_WHEN_  UPDTE 

>  STK_NAME 

>  CLNT_NAME,CLNT_STK_QUAN, 
CLNT_STK_PRCNT_ INVST, 
EMPLR_PH 

>  EMPLR_PH 

>  CLNT_NAHE,EMPLR_NAME, 
ANUL_SLRY,  EHPLR_PH 


CLNT_ID,STK_ABRV,TXN_DTE  >  BRKP_  RECUND,  CLNT_STK_TX  N, 

NUH_STK_CLNT_PUR 

Exhibit  3.3 
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A  cursory  look  at  the  Wampum  Brokerage  requirements  in 
terms  of  FDs  show  the  apparent  loss  of  several  data  elements 
(e.q.  ,  gain/loss  data).  In  many  instances  a  data  element 
appearing  on  a  user  requested  output  can  be  derived  from 
other  data  elements.  Therefore,  it  is  not  required  to  store 
derivable  data  element  values  in  the  user's  data  base.  The 
data  base  administrator  must  weigh  the  cost  of  storing  and 
maintaining  data  elements  values  that  can  be  derived  from 
other  sources  against  the  benefits  of  faster  retrieval  if 
the  data  elements  values  are  resident  in  the  user's  data 
base.  of  the  ten  derivable  items  on  the  output  examples 
only  two,  CLNT_STK_QUAN  and  CLNT_STK_PRCNT_INVST,  were  se- 
lected for  actual  storage.  However,  the  derivation  of 
"GAIN/LOSS  PERCENTAGE  WHEN  RECOMMENDED:"  requires  the  intro- 
duction of  data  elements  TOT_AMT_WHEN_RECMND  and 
TOT_ND"M_WHEN_RECHND.        (See   definitions    below.) 

GN_LS_PBCNT_WHEN_RECMND  = 

TtOT_AMT_WHEN_RECMND    -     (TOT_N0M_WHEN    RECMND    *    RCNT_QI)T)) 
/     (TOT_NUM_WHEN_BECMND    *    RCNT_QUT    *    TOO) 

This  calculation  results  in  the  percent  of  chanqe  with  re- 
spect to  the  most  recently  quoted  stock  amount.  The  follow- 
inq  definitions   should   provide   additional   clarity. 

TOT_AMT_WHEN_RECMND   =    Summation    of    AMT_CLN T_STK_TXN    for 

each    stock    when    BRKS_RECMND   =    "yes". 

TOT_NUM_WHEN_RECHND   ■    Summation    of    NIJM_CLN  T_STK_TXN    for 

each    stock    when    BRKR_RECMND    =    "yes". 

If    these      data    elements   were      not   permanently   stored      in   the 

data   base,      it    would   require      traversals   of   all   transactions 
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for   the   given   stock   performinq   comparisons   and   summations   as 
described   above. 

It  is  important  to  have  a  clear  statement  of  user  re- 
quirements. Without  a  clear  statement  of  user  requirements, 
an  inappropriate  transf oraation  of  user  requirements  into 
functional  dependencies  is  likely  to  cause  data  base  integ- 
rity problems  and  maintenance  anomalies  to  surface  durinq 
the  use  of   the   data   base. 

3.  4  Synthesize   a   Normalized   Schema    for   Hampjim   j3ro.kera.fle 

Instead  of  a  complete  manual  execution  of  Bernstein's  al- 
gorithm using  the  functional  dependencies  in  Exhibit  3.3, 
useful  instances  from  the  case  study  are  provided  for  each 
step  of  the  alqorithm.  Simplification  of  the  compound  right 
sides  of  the  given  functional  dependencies  is  done  prior  to 
the  initial  step  of  the  synthesis  algorithm  (see  Exhibit 
3.  4A)  because  an  FD  of  the  form  X  >  A,B  can  always  be  re- 
written  as   X   >    A   and   X   >   B. 
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A)  STK_NAME  >  STK_ABRV 

B)  STK_NAME  >  RCNT_QtJT 

C)  STK_NAME  >  RCNT_VOL 

D)  STK_NAME  >  STK_LAST_tJPDTE 

S)  STK_NAKE  >  TOT~AMT_HHEN_RECMND 

F)  STK_NAHE  >  T0T~N™~WHEN~REC.,1ND 

G)  STK_ABEV  >  STK_NAni 
H)  STKlABRV,CLNT_ID  >  CLNT_NAME 

I)  STK_ABHV,CLHT_ID  >  CLNT_STK_QO  AN 

J)  STK_ABRV,C1HT_ID  >  CLNT~STK    PRCNT_IN VST 

K)  STK_ABRV,CLNtIiD  >  EMPLR_PH~ 

L)  EHP1R_NAME  >  EMPIR_PH 

H)  CLUT_ID  >  CI,NT_NAME 

N)  CLNT^ID  >  EMPLR_NAME 

0)  CLHT_ID  >  ANt!I_SLRY 

P|  CLHT_ID  >  EMPIR_PH 

Q)  CLNT_ID,STK_ABRV,TXN_DTE  >  BRKR_RECMND 

R)  CLNT~ID,STK~ABRV,TXN_DTE  >  CLNT_STK_TX N    PRC 

S)  CLNT_ID,STK_ABRV,TXN_DTE  >  NUM_STK_CLNT~PIJR 

Exhibit   3.UA 


The  first  step  of  Bernstein's  algorithm,  eliminate  extra- 
neous attributes,  identifies  STK_ABRV  as  an  extraneous  at- 
tribute in  the  FD  H,  STK_ABRV,CLNT_ID  >  C1NT_NAME  (see  Ex- 
hibit 3.4B).  As  shown  in  Exhibit  3.«B,  the  closure 
(graphically  indicated  by  a  plus  sign)  of  CLNT_ID  includes 
CLNT_NAHE  which  indicates  that  CLNT_IE  alone  functionally 
determines  CLNT_NAHE.  The  algorithm  states  that  any  extra- 
neous attributes  on  the  left  side  of  an  FD  must  be  eliminat- 
ed as  illustrated  by  the  removal  of  STK_ABRV  for  FD  H  in  the 
final    statement    of   Exhibit   3.4B. 
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1)      Eliminate   extraneous  attributes. 

H)       STK_ABBV#CLNT_ID   >    CLNT_NAME 

Find  closure  of  CLNT_ID: 

CLNT_ID+    ■    CLNT_ID,CLNT_NAME,EMPLR_NAHE, 
AKOL_SLRY,EMPLE_PH 

H)   CLNT_ID  >  CLNT_NAME 

Exhibit  3.  UB 

The  second  step  of  Bernstein's  alqorithm  establishes  a 
non-redundant  covering  from  a  list  of  FDs.  This  is  accom- 
plished by  removing  an  FD  from  the  list  of  FDs  and  finding 
the  closure  of  the  removed  FD's  left  side  using  the  remain- 
ing FDs.  If  the  closure  of  the  removed  FD's  left  side  con- 
tains the  removed  FD's  right  side  then  the  FD  is  considered 
redundant.  Exhibit   3.4c      indicates      that      the   closure      of 

CLNT_ID,  the  left  side  of  FD  P,  contains  EMPLE_?H,  the  right 
side  FD  P,  without  the  use  of  FD  P.  Thus,  FD  P  is  consid- 
ered  redundant   and  is  removed   from  the   list   of  FDs. 

2)      Find  covering. 

P)       CLNT_ID    >    EHP1B_PH 

Find   closure  of  CLNT_ID   without 
functional   dependency   P: 

CLNT_ID+    =    CLNT_ID,CLNT_NAHE,EaPLE    NAHE, 
ANUL_SLHy,EMPLE_PH 

Bemove   FD    P   from   list   of   FDs 

Exhibit   3.4C 
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Step  three  of  Bernstein's  algorithm  partitions  the  FDs 
into  groups  that  have  identical  riqht  sides.  Exhibit  3.4D 
illustrates  the  creation  of  six  partitions  from  the  remain- 
ing  FDs. 

3)       Partition. 

STK_NAHE  >    STK_ABEV,ECNT_QUT, 

RCNT_V0L,STK_LA5T_UPDTE, 

TOT_AMT_WHEN_RECKND, 

T0T_NUM_HHEN_EEC,1ND 

STK_ABEV  >    STK_NAM2 

CLNT_ID  >    d.NT_NAME,ANUL_SLRY 

STK_ABBV,CLNT_ID  >   C1NT_STK_QIIA  N, 

CLNT_STK~PRCNT_INVST 

CLNT_ID,STK_ABRV,TXN_DTE  >  BRKR_RECMND, 

CLNT_STK_TXN_PRC, 
NUM_STK_CLNT_PUR 

EMPLR_NAME  >    EMPI.R_PH 

Exhibit    3.4D 

It  is  possible  that  the  left  sides  of  the  partitioned 
groups  of  FDs  in  Exhibit  3.tD  nay  be  equivalent  keys.  If 
left  sides  of  partitioned  groups  are  equivalent  keys  then 
step  H  of  Bernstein's  algorithm  requires  that  they  be 
merged.  Equivalent  keys  exist  if  the  closures  of  the  left 
sides  of  partioned  groups  are  equal.  Exhibit  3.4E  indicates 
that  the  closures  of  STK_NAHE  and  STK_ABRV  are  equal  and  the 
partitions   containinq   these  as    left   sides   should   be   merqed. 
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4)      Herge  equivalent   keys. 

Construct   the  closure  of  each   of   the   left  sides: 

STK_NAME  +    =    STK_tiAME,STK_ABRV,RCNT_QUT,BCNT_VOL, 
STK_LAST_UPDATE,TOT_AMT    WHEN    RECMND 
TOT_NIJH_WHEN_RECFIND 

STK_ABEV+    =    STK_ABRV,STK_NAHE,RCNT_Q[JT,RCNT_VOL, 
STK_LAST_UPDATE,TOT_AMT_WHEN_RECMND 
TOT_NUM_WHEN_RECMND 

Exhibit    3.  4E 

The  final  step  of  Bernstein's  algorithm  constructs  rela- 
tions from  the  merged  partitions  of  the  previous  step  by  es- 
tablishing relation  identifiers,  enclosing  attributes  in  pa- 
rentheses, and  underlining  key  attributes  as  seen  in  Exhibit 
3.4F. 


5)       Construct    relations. 

El        (STK    NAME. STK    ABRV  .  BCNT_0»T  ,  RCNT_VO  T, 
STK_LAST_aPDTE,T0T_AMT_WHEN_REC.1ND, 
TOT_HUM_WHEN_BECMND) 

E2    (CLHT    ID, CIST    NAHE.ANUL    SLRY  .EHPI.B_M»MF.) 

B3    (STK    ABRV.CINT    ID.CLNT    STK    OIIAW. 
CLNT_STK_PBCNT_INVST) 

B4     (CLHT    ID. STK    A3BV.TXN    DTE.BBKR    RECMND. 
CLNT_STK_TXN_PBC,NUM_STK_CLNT_PIJB) 

E5     (EBPLB    NAME.EMPLR    PHI 

Exhibit    3.4F 

Exhibit  3.<»F  illustrates  the  output  of  Bernstein's  algor- 
ithm with  respect  to  the  relational  model.  The  next  section 
describes  how  the  output  of  Bernstein's  algorithm  can  be  ap- 
plied   to   the   network   model. 
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3-5  Correlation   of   Out£Ut   from   Bernstein's   Algorithm   and 
Network   Entities 

Each  of  the  five  relations  in  Exhibit  3.  <*F  become  an  oc- 
currence in  the  RECORD  entity  of  the  conceptual  schema  in 
Exhibit  2.1.  Likewise,  the  data  elements  within  the  rela- 
tions in  Exhibit  3.4F  becomes  occurrences  ir.  the  DATA 
ELEMENT  record  of  the  conceptual  schema  in  Exhibit  2.  1.  The 
appropriate  links  between  RECORD  and  DATA-ELEHENT  records  in 
the  conceptual  schema  are  established  using  the  POPULATED-BY 
and  SBOUPED-IN  sets.  Subsequent  chapters  give  the  details 
of  creating  data  elements  and  records  from  these  relations. 
One  can  assume  at  this  point,  i.e.,  the  completion  of  Bern- 
stein's alqorithm  using  FDs,  that  data  elements  and  records 
for  a  user's  data  base  requirements  have  been  added  to  the 
meta  data  base  that  is  being  manipulated  by  DB_GEN  (see  Ex- 
hibit   2.1). 

3.6  Nonfunctional   Dependencies  a_nd   fie.rn.steinj.s  JllaoEAthm 

The  functional  dependencies  shown  in  Exhibit  3.4A  result 
in  the  establishment  of  data  elements  and  records  for  the 
network  schema  beinq  created  through  the  use  of  DB_GEN. 
But,  as  stated  by  Phillip  Bernstein,  "Clearly  though,  not 
every  logical  connection  in  the  world  is  functional." 
(BERN76)  In  the  section  of  Bernstein's  1976  paper  discuss- 
ing "The  Synthesis  Problem  in  Nonfunctional  Relationships", 
Bernstein      never   clearly      addressed    how      one    determines      the 
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need  for  a  nonfunctional  dependency.  However,  one  must  as- 
sume that  a  nonfunctional  dependency  exists  when  the  policy 
of  an  organization,  for  which  the  data  base  is  being  de- 
signed, specifies  that  a  specific  value  of  an  item,  e.g., 
invoice  number,  determines  a  set  of  instances  of  another 
item,  e.g.,  product  name.  In  the  case  of  the  Wampum  Broker- 
age case  study,  the  STOCK  ACTIVITY  display  (see  Exhibit  2.3) 
indicates  that  a  given  instance  of  STK_NAME  (e.g.  Interna- 
tional Business  Machines) ,  determines  a  set  of  instances  of 
CLNT_NAME  (e.g.,  Joe  Sly,  Tycoon  Mary,  Bags  Moonie,  Bull 
Francis,  and  T.  Howell  III) .  Because  Codd's  first  normal 
form  requires  that  none  of  the  domains  of  a  relation  have 
elements  which  are  themselves  sets,  the  STK_NAME  and 
CLNT_NAME  data  elements  of  Wampum  Brokerage  must  be  ir.  sepa- 
rate relations.  Therefore,  in  order  to  establish  the  neces- 
sary associations  between  instances  of  the  relation  that 
STK_MAME  appears  in  (i.e.,  relation  IM  of  Exhibit  3.  4F)  and 
the  instances  of  the  relation  that  CLNT_NAME  appears  in 
(i.e.,  relation  K2  of  Exhibit  3.4F),  a  relationship  must  be 
established  between  relation  El  and  relation  B2  of  Exhibit 
3.«F.  The  implementation  of  such  relationships  reguires 
some  form  of  a  data  structure  to  link  the  various  relations' 
instances,  e.g.,  pointers  are  used  in  the  network  model  and 
a  matching  of  data  element  domains  is  used  in  the  relational 
model.  with  respect  to  the  relational  schema,  Bernstein 
claimed  that  ".  .  .  all  connections  among  attributes  in  a 
data   base   description   can    be   represented  by   FEs.      As   long   as 
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connections  are  functional  there  is  of  course  no  problem. 
Nonfunctional  connections  require  special  attention." 
(BERN76)  Bernstein  transformed  each  NFD  into  an  FD  by  con- 
catenating the  riqht  side  of  an  NFD  to  the  left  side  of  the 
NFD  and  introduced  a  unique  variable,  theta,  on  the  now  emp- 
ty riqht  side  of  what  was  an  NFD.  For  example,  the  NFD  de- 
scribed previously  for  the  Wampum  Brokerage  case  study  ap- 
pears   as   follows; 

S?K_NAME    >>    CINT_NAHE 
This   NFD      is   transformed   into   an      FD    by   moving     CLNT_NAHii   to 
the  left  side  with   STK_NANE  and      placing   a    unique   theta   data 
element,    THETA_2,    on   the  riqht   side    (see  below). 

STK_NAME,CLNT_N»tlE    >    THETA_2 
By   adding   this   FD   to  the   list    of   FDs   in  Exhibit   3. UA   and  ap- 
plying   Bernstein's      synthesis   algorithm,      a   new      relation   is 
established    (see   below)  . 

Rfc  (STK_NAME,CLNT_NAME,THETA_2) 
For  each  instance  in  the  cross-product  of  the  domains  of 
STK_NAME  and  CLNT_NAHE  in  the  above  relation,  if  THETA_2  has 
the  value  of  "1"  then  a  relationship  exists  between  the  re- 
spective instances  of  STK_NAME  and  CLNT_NAME  and  if  THETA_2 
has  a  value  of  "0"  then  a  relationship  does  not  exist  be- 
tween   the    respective   instances    of    STK_NAi1E    and   CLNT_NAME. 

A  complete  list  of  NFDs  for  the  output  examples  of  Wampum 
Brokerage  case  study  (see  Exhibits  2.3  and  2.4)  appears  in 
Exhibit  3.5  followed  by  a  transformation  of  the  NFDS  into 
FDs   as   seen   in   Exhibit    3.6. 
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1)  STK_NAME  »    CLNT_ID 

2)  STK_NAME  »    CLNT_NAME 

3)  STK_NAME  »    CLNT_STK_QO  AN , 

4)  STK_NAME  »    CLOT    STK    PRCNT    INVST, 

5)  STK_NAME  »    EMPLS    PH~ 

6)  CLNT_NAME  »    STK    ABEV 

7)  CLNT_ID,STK    ABEV  »    TXN~DTE, 

8)  CLNT_ID,STK_ABEV  »    BBKB    EECilND, 

9)  CLNT_ID,STK_A3HV  »    CLNT_STK_TXN_PRC, 
10)  CLNT_ID,STK_A3EV  »    NUM    STK_CLNT    PUE 


Exhibit    3.5 


1)  stk_nahe,clnt_id 

2)  stk_name,ci.nt  name 

3)  stk_name,ci,ntIstk_qoan 

4)  stk_nahe,cint_stk_pecnt  invst 

5)  stk_name,empi.h_ph 

6)  clnt_name,stk  abev 

7)  cint_nai1e,stk_abev,teans_dte 

8)  clnt_name,stkIabev,bbkr  EECMND 

9)  CLNT_NAHE,STK_ABEV,CLNt3sTK_TXN    DTE 
10)  CLNT_NAME,STK_ABKV,NUH_STK_CLNT~P!JR 


> 

THETA     1 

> 

T1IETA_2 

> 

THETA_3 

> 

T!IETA_4 

> 

THETA_5 

> 

THETA_fc 

> 

THETA^7 

> 

THETA~8 

> 

THETA~9 

> 

THETA    10 

Exhibit  3.6 


As  illustrated  in  Exhibit  3.7,  several  new  relations  have 
been  created  from  the  FDs  in  Exhibit  3.fc  for  the  establish- 
ment of  the  relationships  between  the  original  set  of  rela- 
tions in  Exhibit  3.4F. 
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El     (STK    NAflE.STK    ABBV.BCNT    OUT.RCNT    VOL. 
STK_LAST_UPDTE,TOT_ABT_WH£N_RECBND, 
TOT_NUB_HHEN_RECBND) 

B2     (CLNT_I_D,CLNT_tJAME,  ANaL_SLBY,E«PLR_NAKE) 


B3     [STK    ABRV.CLNT    ID.CLNT    STK    QTJAN. 
CLNT_STK_PBCNT_INVST,THETA_  1) 

M     (OuST    ID, STK    ABRV.TXS     DTE,  BRKR    RECMND. 
CLNT_STK_TXN_PRC,NUM_STK_CLNT~PUR, 
THETA_7) 

R5     (EHPLR    HA3E.EMPLR    PH) 

Bfc     (STK    SAflE.CLHT    NAHE. THETA    2) 

B7     (STK    NABE.CLNT    STK    OUAN. THETA    3) 

R8     (STK    NABE.CLNT    STK    PRCNT    INVST.THETA    4) 

R9     (STK    NA3E.EMPLR    NAHE.THETA    5) 

B10      (CLST    NAME. STK    ABHV, THETA    6) 

R11     (CLHT    ID, STK    ABRV,BRKR    BECBND, THETA    8) 

B12     (CLMT    ID, STK    ABBV,  CLNT    STK    TXN    PRCNT, THETA    9) 

R13     (CLMT    ID. STK    ABBV,  NUB    STK    C1NT   PRC.  THETA    10) 

Exhibit    3.7 

By  introducing  a  unique  theta  for  each  NFD ,  one  is  given 
the  flexibility  to  introduce  multiple  relationships.  For 
instance,  both  relations  E7  and  R8  have  been  established  as 
relationships  between  relations  El  and  R3.  Generally,  mul- 
tiple relationships  are  introduced  when  they  are  not  needed 
if  all  the  FDs  generated  from  NFDs  are  introduced.  Bern- 
stein provided  no  insight  into  the  outcome  of  this  method. 
Thus,   the   data  base  designer  must   be  called  upon   to  make 
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sone  lodgements  as  to  which  of  the  FDs  represent  the  needs 
of  the  organization  in  terns  of  inherent  data  structures. 
In  the  case  of  Wampum  Brokerage,  a  data  base  designer  may 
decide  that  only  THETA_1  in  relation  R3  and  THETA_7  in  rela- 
tion R4  are  reguired  for  the  correct  representation  of  user 
requirements  in  a  relational  model.  In  reference  to  Exhibit 
3.7,  the  relationship  established  between  relations  E1  and 
R2  by  relations  R6  and  R10  are  represented  by  the  THE7A_7 
data  element  in  relation  B3  because  STK_ABRV  and  STK_NAME 
represent  relation  R1  and  CLNT_ID  and  CLNT_NAME  represent 
relation  R2.  Relations  R7  and  R8  represent  the  need  for  a 
relationship  between  relations  R1  and  R3.  Each  of  the  rela- 
tions R1  and  R3  contain  STK_NAME.  Thus,  this  relationship 
already  exists  without  the  need  of  relations  R7  and  Rfl. 
Similarly,  relations  R11,  R12,  and  R13  represent  a  need  for 
a  relationship  between  relations  R3  and  R4.  Each  of  the  re- 
lations R3  and  R4  contain  CLNT_ID  and  STK_ABRV.  Therefore, 
this  relationship  already  exists  without  the  need  of  rela- 
tions B11,  R  12,  and  R13.  Relation  R9  indicates  a  need  for  a 
relationship  between  either  relations  R1  and  R2  or  Rl  and 
E5.  The  reason  that  a  choice  exists  concerning  the  estab- 
lishment of  the  relationship  requested  by  relation  F9  is 
that  EHPLR_NAME  appears  in  both  relations  R2  and  R5.  Rela- 
tion 83  already  provides  a  relationship  between  relations  R1 
and  R2.    Thus,    relation   R9   is   not   necessary. 
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Although  internally  the  network  model  addresses  relation- 
ships in  a  significantly  different  manner  than  the  relation- 
al model,  the  problems  associated  with  transforming  NFDs 
into  sets  (the  network  model  term  for  relationship)  neces- 
sary for  the  network  model  to  meet  user  requirements  remain. 
This  transformation  process  is  addressed  in  more  detail  in 
the  following  chapter.  Data  Base  Initialization  and  Inter- 
pretation. 
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Chapter  4 

DATA  BASE  INITIALIZATION 

AND 

INTEBPHETATION 


The  data  base  initialization  module,  DB_INIT,  makes  use 
of  Bernstein's  alqorithm  to  establish  user  required  data 
base  entities  (i.e.,  data  elements,  records,  and  sets). 
However,  Bernstein  is  creating  a  relational  model  and  the 
system  described  in  this  research  is  producinq  a  network 
model.  Thus,  manipulation  of  the  output  of  Bernstein's  nor- 
malization algorithm  to  transform  it  from  a  relational  model 
to  a  network  model  must  be  accomplished.  This  chapter  ex- 
plains how  dependencies  among  data  elements  are  entered  into 
DB_GEN  and  how  those  dependencies  are  modified  by  DB_GEN  it- 
self and  by  DB_GEN  through  interaction  with  the  data  base 
designer  to  produce  the  network  records  and  sets  required  to 
meet    the   user's    needs. 

4.  1  Establish   Position   in    DB_GEN 

Before  pursuing  an  indepth  look  into  the  functions  of 
DB_INIT,  the  DB_GEN  response  via  menu  traversals  is  given. 
On  entering  DB_GEN  one  must  select  an  existing  data  base  or 
create   a  new      data  base    (see    Exhibit      4.1).         Selection   four 
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generates      the    primary      menu      of      services   with      respect      te 
STOCK-DB    (see  Exhibit   4.2) . 


1            *** 

SELECT    A    DATA    BASE      *** 

1            1) 

CREATE    DATA    BASE 

1                   2) 

OPTION-DB                                                                              | 

1                   3) 

BOND-DB                                                                                    J 

1                   t) 

STOCK-DB                                                                                 J 

1                   X) 

EXIT                                                                                            | 

1                     MAKE    A    SELECTION    ===>    4                                                   J 

Exhibit    4.  1 


***     PRIMARY  MENU     *** 

1)  DATA  BASE  INITIALIZATION 

2)  DATA  ELEMENT  UPDATE 

3)  RECORD  UPDATE 

4)  SET  UPDATE 

5)  DATA  BASE  UPDATE 

6)  PRINT  DATA 

7)  SCHEMA    CREATOR 
X)  EXIT 


MAKE    A    SELECTION 


=>  1 


Exhibit  4.2 


4.2  Eniii  of  Funciional  and  Nonfunctional  Dependencies 

Exhibit  4.3  provides  the  data  base  administrator  with 
several  functions  which  may  be  performed  and  provides  enouqh 
information  to  maintain  clarity  of  position  and  operation 
for  the  user.  The  formats  for  entry  of  functional  dependen- 
cies (FDs)  and  nonfunctional  dependencies  (NFDs)  are  consis- 
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tent  with  those  of  the  previous  chapter  and  with  most  of  the 
literature.  if  the  user  were  not  familiar  with  the  neces- 
sary formats,  help  is  provided  by  selectinq  the  appropriate 
number  of  a  function  and  then  failing  to  provide  an  entry 
(see  Exhibit  4.3).  The  results  of  this  help  feature  appear 
in  Exhibit  4.4. 


***   DATA  BASE  INITIALIZATION  *** 

1)  CREATE    FUNCTIONAL    DEPENDENCY 

2)  CBEATE    NON-FUNCTIONAL    DEPENDENCY 

3)  INITIALIZE    DATA    BASE 
DELETE    DEPENDENCY    ... 

4)  STK_ABRV  >         STK_NAME 

5)  CLNT_ID  >         CLNT_HAME 

6)  STK_ABRV  >>      CLNT    ID 


X)        EXIT 

MAKE    A    SELECTION    ===>    2 


Exhibit   H.3 

***      CREATE    NON-FUNCTIONAL    DEPENDENCY       *** 

FORMAT: 

left_side  >  right_side 

Where   either   side  can    be    a   concatenation 
of   several   elements   separated    by   commas. 

MAKE    ENTRY 
==>      STK_ABRV,CLNT_ID    >>    TXN_DTE|BRKR    RECMND 


Exhibit    4.4 
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All  riqht  sides  of  dependencies  are  simplified  to  a  single 
attribute  by  the  introduction  of  new  dependencies  (see  num- 
bers 7  and  8  of  Exhibit  4.5). 


J             ***      DATA    BASE    INITIALIZATION 

*** 

J                      D 

CREATE    FUNCTIONAL    DEPENDENCY 

I                    2) 

CBEATE    NON 

_FUHCTIONAL 

DEPENDENCY             i 

1                   3) 

INITIALIZE 

DATA    BASE 

1                     DELETE    DEPENDENCY    .    . 

I                           «) 

STK    A3BV 

>         STK_ 

VABE 

1                          5) 

CLNT    ID 

>         CLNT. 

NAME 

1                          6) 

STK_ABRV 

>>    clnt] 

"id 

1                        7) 

STK_ABRV, 

CLNT_ID      »" 

TXN 

DTE                  | 

1                         8) 

STK^ABRV, 

CLNT~ID       » 

BRKR 

_RECHND       | 

J                   X) 

EXIT 

I                     HAKE 

A    SELECTION    ===>    1 

Exhibit  4.5 

Hith  the  exception  of  INITIALIZE  DATA  BASE  the  remaininq  se- 
lections of  Exhibit  4.3  should  be  self  explanatory. 

4. 3  Initialijat ion  of  the  Useris  Data  Bas_e.  Schema 

INITIALIZE  DATA  BASE  transforms  FDs  and  NFDs  into  data 
base  entities  (i.e.,  data  elements,  records,  and  sets). 
Bhile  the  user  is  creating  the  inputs  representative  of  user 
requirements  of  the  data  base,  INITIALIZE  DATA  BASS,  in  con- 
junction with  the  print  options,  should  be  used  frequently 
as  a  design  aid.  However,  data  base  customization  should  be 
restricted  until  user  requirements  stabilize.  When  a  data 
base  is  reinitialized,   a   complete  regeneration  of  entities 
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occurs  and  any  previous  entity  customization  is  lost.  Al- 
though DB_INIT  provides  a  fast  and  easy  way  to  initiate  a 
sound  schema,  the  customization  modules  in  chapter  5  contin- 
ue to  make  major  changes  in  requirements  easy  to  incorpo- 
rate. 

4.3.1  Creation   of   Data   Element   and   Record  Entities 

As  discussed  in  Chapter  3,  Bernstein's  Alqorithm  and  User 
Requirements,  records  and  data  elements  are  derived  from 
functional   dependencies   using    Bernstein's   alqorithm. 

4.3.2  Creation  of  get  Entities 

The  remainder  of  this  chapter:  1)  contrasts  the  rela- 
tional DBMS's  relationship  with  the  network  DBKS's  set,  2) 
discusses  a  necessary  enhancement  to  Bernstein's  alqorithm 
to  enable  the  NFD-to-set  conversion,  3)  explains  the  NFD- 
to-set  conversion  technique,  and  4)  discusses  the  creation 
of    the   set   entity. 

4.3.2.1    Contrast   the   Relational  EMS   Relationship,  with 
the    Network   DBHS    Set 

Functional  dependencies  deal  with  intra-record  relation- 
ships, whereas  nonfunctional  dependencies  are  concerned  with 
relationships  between  records.  Because  a  relational  model 
uses  only  one  structure  (i.e.,  a  relation),  few  interpreta- 
tions need  to  be  made  by  Bernstein's  alqorithm  to  distin- 
guish   relations      from   relationships.         The      following   steps. 
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implicitly  derived  from  Bernstein  (BERN76)  ,  outline  the 
method  used  to  synthesize  a  relational  schema: 

1)  Enter  functional  and  nonfunctional  dependencies 

2)  Convert    NFDs   to  FDs 

3)  Execute   Bernstein's   algorithm 

The  relational  model  establishes  relationships  throuqh  a 
foreign  key  (for  1-to-1  relationships)  or  through  a  separate 
relation  (for  1-to-n  and  m-to-n  relationships)  that  contains 
attributes   of   the      relations    to    be   linked.  In   Exhibit   4.6 

the  relation  entitled  STK_CLNT  allows  users  to  ask  the  ques- 
tions "Given  a  stock,  who  are  all  the  clients  that  own  that 
stock?"      and    "Given   a   client,    what   stocks    are   owned?" 


I 


STOCK 


|     STK-ABRV 
|     STK-NAHE 


I 


CLIENT 


I  CLNT-ID 
|  CLNT-NAME 


I  STK-CLNT 

I 

|     STK-ABRV 
I     CLNT-ID 


Exhibit    4.6 

A  network  model  uses  a  cyclic  pointer  structure  to  estab- 
lish relationships.  Exhibit  4.7  shows  a  network  model  rep- 
resentation of  the  relational  model  shown  in   Exhibit  4.6. 


STOCK 


|     STK_ABRV 
I     STK_NAHE 


OWNED    BY 


«- 


OBNS 


|          CLIENT 
-»] 

I    CLNT_ID 
- — J    CLNT_NA«E 


Exhibit    4.7 
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Network   relationships     can   be   described  by     their   respective 

owner    and    member    records.      In  general,    the   left   side    (IS)     of 

an    NFD   identifies      the   owner    record   and  the      right   side    (HS) 

specifies    a   member      record.         Exhibit    a. 8    presents      two  NFDs 

used   to  create   the   graphic   schema   in    Exhibit    4.7. 

S:       STK_ABRV      »      CLNT_ID 
T:       CLNT_ID         >>       STK_ABEV 

Exhibit    4.8 

When  creating  the  relational  model,  the  NFDs  were  converted 
to  FDs  and  all  the  dependencies  were  used  as  input  to  Bern- 
stein's algorithm.  With  a  network  model,  one  must  know 
which  records  exist  before  NFDs  can  be  interpreted.  There- 
fore Bernstein's  algorithm  is  run  to  completion  with  FDs 
only.  Candidate  keys  of  the  recently  created  records  now 
provide  a  means  to  interpret  left  and  right  sides  of  NFDs 
into  owner  and  member  records.  An  evaluation  of  NFDs  in  Ex- 
hibit 4.8  results  in  the  selection  of  STK_ABRV  to  be  a  can- 
didate key  of  STOCK  and,  therefore,  the  owner.  Similarly, 
CLNT_ID  is  a  candidate  key  of  CLIENT  and  therefore  the  mem- 
ber. Requiring  the  user  to  enter  only  NFDs  whose  right  and 
left  sides  evaluate  to  a  previously  derived  record  is  far 
too  restrictive.  This  is  especially  true  when  the  user  does 
not  have  any  way  of  knowing  what  the  candidate  keys  are  when 
NFDs  are  entered.  Suppose  for  example,  an  NFD,  S,  (see  Ex- 
hibit 4.8)  was  changed  to  STK_ABRV  >>  CLNT_NAME  where 
CLNT_NAME  is  not  a  candidate  key.  The  user's  meaning  re- 
mains  clear.         CLNT_NAME      appears   in    the  CLIENT      record   as  a 
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non-priae  attribute  so  the  same  result  is  expected.  This 
flexibility  introduces  several  NFD  interpretation  problems. 
Before  addressinq  these  problems,  it  is  necessary  to  study 
an   enhancement    of    Bernstein's   algorithm. 

4.3.2.2  Check   for   Missing   but   Implied    Dependencies 

Converting  an  NFD  to  a  set  requires  a  minor  modification 
to  the  output  of  Bernstein's  algorithm.  Consider  an  NFD, 
STK_ABRV      »      EMPLR_PH.  The      NFD      contains      an      attribute 

£BPLR_PH  which  is  not  a  part  of  any  key,  i.e.  ,  it  is  a  non- 
prime  attribute.  In  this  case  a  substitution  of  the  respec- 
tive prime  attribute (s)  must  be  made  and  a  search  for  a 
matching  candidate  key  performed.  With  the  FDs  given  in  Ex- 
hibit 4.9,  the  non-prime  attribute  EMPLB_PH  appears  in  two 
records. 

0)       CLNT_ID  >  EMPLR_PH 

NFDs    S  V)        EHPLE_NAME      >  EHPLR_PH 

FDs    in    ==>  W)        STK_ABHV  »       EHPuTpH 


RELATIONS  B1     (CLNT    ID,  EBPLB-PH) 

OUT       ==>  82     (EHPLB    N  AHE,  EMPLK-P  H) 

Exhibit    4.9 


In  this  case,  the  FDs  do  not  provide  enough  information  to 
create  a  schema  that  would  be  optimal  in  a  "real  world"  en- 
vironment and  human  intervention  is  required.  The  standard 
form  of  Bernstein's  algorithm  produces  two  relations  shown 
in  Exhibit  4.9.  There  is  attribute  redundancy  as  EMPLR_PH 
appears   twice   in      the  relations.         The   designer      now   has   two 
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options  for  the  substitution  of  prime  attributes  for  non- 
prime  attributes:  1)  a  substitution  of  the  prime  attributes 
CLNT_ID  may  be  made  producing  STK_ABKV  »  CLNT_ID  or  2)  the 
prime  attribute  EHPLR_NAME  may  be  substituted  producing 
STK_AB2v  »  EHPLR_NAHE.  Any  non-prime  attributes  that  ap- 
pear more  than  once  in  FDs  after  application  of  steps  1  and 
2  of  Bernstein's  algorithm  (see  Exhibit  3.4C)  indicate  that 
additional  semantic  information  is  required  of  the  user. 
Given  the  FDs  of  Exhibit  4.9,  at  least  one  of  the  two  FDs  in 
Exhibit   4. 10    must  be   true. 

P)       CLMT_ID  >         EMPLR_NAME 

Q)        EMPLR_NAHE       >         CLNT_ID 

Exhibit    4.10 

In  this  case,  P  is  known  to  be  true  by  the  data  base  design- 
er and  a  less  redundant  schema  results  (see  Exhibit  4.11). 

Relations     E1  (CLNT_ID) 

OUT   ==>     R2  (EMPLR_NAME,EMPLF-PH) 

Exhibit    4.11 
All  this   concern    for   removal   of    a   single   redundant   attribute 
is   questionable.         However,    another   case  illuminates   the   im- 
portance of  this   concept   better    (see    Exhibit    4.12). 

FDs    in    =>  H)        STK_NA«E  >         RCNT_QUT 

G)       STK_ABRV  >  RCNT_Q0T 


RELATIONS  El     (STK_ABR V, RCNT    QUT) 

OUT       ==>  R2     (STK    MAKE,  RCNT    OUT) 

Exhibit    4.  12 
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In   this  case   the    data   base  designer    may   know    that   there   is    a 

bijection    (i.e.,    STK_ABRV    < >    STK_NAME)       between   the   prime 

attributes    STK_NAME   and  STK_ABRV.      This  allows   the   system   to 

produce  a   single  record   schema    (see   Exhibit   4.13). 

RELATIONS 

OUT      ==>  R1     (STK    NAME.STK    ABRV,  RCNT-QUT) 

Exhibit    4.  13 

The  purpose  of  Bernstein's  1976  paper  was  ".  .  .  to 
develop  a  provably  sound  and  effective  procedure  for  syn- 
thesizing relations  satisfying  Codd's  third  normal  form  from 
a  given  set  of  functional  relationships.  Also,  the  schema 
synthesized  by  our  procedure  is  shown  to  contain  a  minimal 
number  of  relations. "  (BERN76)  The  FDs  added  by  the  data  base 
designer  as  presented  in  the  above  Exhibits  must  be  existing 
facts.  By  addressing  these  facts  the  data  base  designer  can 
produce  a  less  redundant  schema. 

If  additional  semantic  information  is  reguired,  the  data 
base  administrator  is  expected  to  respond  interactively  (see 
Exhibit  4.  14). 


***       SEMANTIC    QUESTION 

*** 

I       BASED 

ON    GIVEN    FDS 

ONE 

OF    THE 

FOLLOWING    MUST       | 

]       BE    TRUE.       CLARIFY 

SEMANTICS    BY    SELECTION.                | 

i       n 

1             2) 

CLNT    ID            < 
EMPLB    NAME 

> 

> 

EMPLR 

NAME                                   1 

CLNT    ID 

J             3) 

CLNT_ID 

> 

EMPLR 

.NAME                                  I 

1       MAKE    A     SELECTION    = 

==>    3 

Exhibit  ».  14 
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The  case  statement  in  Exhibit  4.15  explains  the  action  to  be 
taken,  based  on  the  dependencies  in  Exhibit  4.9  and  the  dis- 
play of  Exhibit  4. 14. 

CASE  menu  selection 
WHEN    1 

replace  either  FD  0  or  FD  V  with  both  FDs  2  and  3 
WHEN    2 

replace  FD  V  with  FD  2 
WHEN    3 

replace  FD  0  with  FD  3 
END  CASE 

Exhibit  4.  15 

Without  this  additional  semantic  information  interpretations 
of  owner  and  member  records  from  NFDs  would  be  purely  arbi- 
trary in  some  situations.  The  fact  that  one  produces  a  less 
redundant  and/or  more  minimal  schema  from  this  added  infor- 
mation  is   a   fortunate  side  effect. 

4.3.2.3  Nonfunctional   Degendenc2zi2rSet   Conversion 

4.3.2.3.1   Convert    Non-E£ime   Attributes   of   an    NFD  to 
Prime   Attributes 

Although  each  non-prime  attribute  can  now  be  identified 
by  a  set  of  candidate  keys  representing  a  single  record, 
concern  remains  about  a  mindless  substitution  of  candidate 
keys  for  non-primes.  This  substitution,  as  a  rule,  would 
still  model  the  users'  needs  but  could  add  unwanted  rela- 
tionships between  entities.  A  subset  of  FDs  and  NFDs  from 
the  Wampum  Brokerage  case  study  is  used  to  illustrate  this 
potential    problem    (see    Exhibit    4.16). 
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FD1: 
FD2: 
FD3: 

FD4: 
FD5: 

STK    ABBV                             > 
CLNT_ID                               > 
STK_ABBV,CLNT    ID      > 
CLNT_ID                               > 
EMPLB_NAME                       > 

STK    NAME 
CLNT_NAME 
STK_CLNT    QDAN 
EMPLR    NAME 
EMPLB_PH 

NFD1: 
NFD2: 
NFD3: 

STK_ABBV 
STK_ABBV 
STK    ABBV 

» 
» 
» 

CLNT_NAME 
STK_CLNT_QUAN 
EMPLR    PH~ 

Exhibit    4. 16 

Any  tine  an  FD  exists  where  the  BS  attribute  represents 
one  record  and  LS  attribute (s)  represent  another  record,  a 
1-to- 1  relationship  exists.  The  existence  of  a  1-to-1  rela- 
tionship in  this  situation  is  based  on  the  definition  of  a 
functional  dependency  which  appears  in  Chapter  1.  Function- 
al dependency  four  (FD4)  in  Exhibit  U.lfc  constitutes  such  an 
FD.  This  relationship,  derived  from  FD4,  is  graphically 
shown  by  the  single- headed  arrow  between  REC0BD2  and  RECORD** 
in   Exhibit    4. 17 


SET2  from 
NFD2 

J 

I 

I 

1 

V 

V 

J  BECOBD3 

J 

1     STK-ABBV 

1     C1NT-ID 

I     STK-CLNT-QUAN 


1  RECORD  1 

J  "stF^ABRV 
I    STK-BAME 


SET1 


from    NFD1 


] 
-»l 


RECORD2 


1     C1NT-ID 
|    CLNT-NAME 


I 

SET3    |  from   NFD3 

1  

I  |          KEC0ED4 

I  J 


»|     EflPLB-NAKE 

I     SMPLB-PH 
I 

Exhibit   i».  17 


I 
SET 4    1    from    FD4 
1 
I 
I 
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Apparent  from  the  model  shown  in  Exhibit  «. 17  is  the  ex- 
istence of  a  transitive  path  from  REConDl  to  RECORD**  through 
REC0RD2.  Nonfunctional  dependency  NFD3  creates  the  unwanted 
transitivity  via  SET3.  In  this  case,  SET3  is  useless  for 
creating  the  STOCK  ACTIVITY  display  and  only  serves  to  add 
complexity  to  the  schema.  Should  a  different  user  applica- 
tion dictate  a  path  from  REC0HD1  to  REC0RD4,  that  relation- 
ship can  still  be  recognized  through  REC0RD2.  Transitivity 
of  this  type  can  be  eliminated  when  the  RS  attribute  of  an 
NFD  is  converted  to  a  member  record.  The  means  by  which 
this  transitivity  is  resolved  is  formally  introduced  by  the 
high  level  algorithm  in  Exhibit  i*.  18  and  expounded  upon 
through   the   example   introduced    in   Exhibits   U.  16    and   4.  17. 

ALGORITHM    TO    CONVERT    NON-PRIME    NED    ATTRIBUTES 
TO    PRIME    ATTRIBUTES: 

BEGIN    ALGORITHM; 

prime- substitute    < non-prime   attribute   in    an    NFD; 

DO   WHILE   prime-substitute  exists    on   the   RS    of   an   FD   and 
the   prime-substitute   has   yet    to   be   considered; 

LOCATE   the   FD    where   the    prime-substitute   attribute 
exists   on   a   RS; 

prime-substitute    < recently    located    FD's    LS; 

END  LOOP; 

END  ALGORITHM; 

Exhibit  U.  18 

The  algorithm  in  Exhibit  ".18   removes  transitivity  from  the 

the  data   base  model  by  tracing   existing  FDs  back  to  their 

left  most  identifier.    This  backtracking  continues  until  no 

further  backtracking  can  be  done,   or,   in  the  case  of  a  bi- 
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jection,  the  prime  substitute  becomes  redundant  with  respect 
to  previous  substitutions.  Without  the  condition  checking 
for  redundant  substitutions  an  endless  loop  could  result. 
In  the  example  presented  in  Exhibit  4.16,  existinq  FDs  trace 
the  non-prime  attribute,  EMPLR_PH,  back  to  its  left  most 
identifier,    CLHT_ID  as  shown   belowj 

CLNT_ID  >  E«PLR_NABE  >  EHPLR_PH. 
The  RS  of  NFD3  in  Exhibit  ".16  becomes  CLNT_ID  instead  of 
EHPLR_NAME  (i.e.,  NFD3  becomes  STK_ABRV  >>  CLNT_ID)  and  the 
transitivity  between  records  is  removed.  With  respect  to 
NFDs,  consistency  has  been  established  for  converting  non- 
prime  attributes  to  prime  attributes.  Note  that  the  algor- 
ithm also  converts  non-prime  attributes  on  the  LS  of  an  HFD 
to  prime  attributes.  In  order  for  owner  records  to  be  in- 
terpreted from  an  NFD's  RS  and  a  member  record  to  be  inter- 
preted from  an  NFD's  LS,  all  NFD  attributes  must  be  prime 
attributes. 

4.3.2.3.2   Establish    Member   Record 

Several  questions  concerninq  the  conversion  of  these  mod- 
ified NFDs  to  owner  and  member  records  remain  unanswered. 
The  high  level  algorithm  in  Exhibit  4. 19  is  used  to  estab- 
lish the  procedure  for  converting  the  HS  of  an  NFD  to  the 
expected  member  record.  Following  the  algorithm,  an  example 
is   provided   to   give  a   further    understanding   of   this    process. 
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ALGORITHM    TO    CONVERT    AN    NFD'S    BS    ATTRIBUTE 
TO    A    MEMBER    RECORD: 

BEGIN    ALGORITHM; 

/**  INPUT    ASSERTION  —   all   non-prime    attributes   of   the 
given   NFD   have  been  converted   to   prime   attributes 
using    the   algorithm   presented   in    Exhibit    4.  18    **/ 

/**   The  RS   of   the    NFD  is  considered  for   the  set    member.**/ 

IF   the   NFD's   RS    is   equivalent   to  an  existing    record's 
candidate   key  (s) 

LOCATE   the   record   whose   keys   are   eguivalent   to   an 
existing   NFD's   RS; 

member-record    < recently    located   record; 

ELSE 

/**   The   intersection   record   created   by   concatenating  **/ 

/**   the   LS   and   RS   of   the   qiven   NFD   is   considered  **/ 

/**    for   the   set   member.  **/ 

CONCATENATE    LS   and   RS   attributes    of    the    given    NFD; 

IF    the    concatenated   attributes   are   equivalent   to  an 
existing    record's  candidate   key(s) 

LOCATE   the   record   whose   keys    are   eguivalent    to  the 
concatenated  attribute's; 

member -record  < recently  located  record; 

ELSE 

/**   There   is  not   enough   information    to    assure   a  **/ 

/**  correct   interpretation  of  the  user's  NFD   as  **/ 

/**    presented.  **/ 

ENDIF 

END   LOOP; 

END   ALGORITHM; 

Exhibit    4.  19 


The  algorithm  in  Exhibit  4.19  first  checks  to  see  if  the  at- 
tribute on  the  RS  of  the  NFD  evaluates  to  an  existing  re- 
cord.   If  it  does  evaluate  to   an  existing  record  then  that 
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record  is  used  as  the  member  record.  If  the  attribute  on 
the  RS  of  the  NFD  does  not  evaluate  to  an  existinq  record 
then  the  concatenation  of  all  NFD  attributes  is  used  to 
search   for   an  intersection  record.  If  an  intersection   re- 

cord exists,  it  is  used  as  the  member  record.  The  existence 
of  an  intersection  record  indicates  an  M-to-N  relationship 
between  the  LS  and  RS  attributes  of  the  nonfunctional  depen- 
dency. As  is  further  clarified  in  Chapter  6,  a  complex  re- 
lationship is  simplified  usinq  an  intersection  record. 
Thus,  the  use  of  an  intersection  record  as  a  member  record 
is  acceptable. 

The  followinq  example  uses  the  NFD,  CLNT_ID,  STK_ABRV  >> 
TXN_DTE,  with  respect  to  the  oriqinal  set  of  records  pro- 
duced for  the  stock  data  base  (see  Exhibit  3.  IF)  ,  to  help 
clarify  the  establishment  of  the  member  record.  The  RS  of 
the  NFD  does  not  clearly  indicate  a  member  record.  TXN_DTE 
is  a  prime  attribute  of  REC0RD4  in  Exhibit  3.  i»F,  so  no  sub- 
stitution is  necessary.  TXN_DTE  is  not  found  to  be  equiva- 
lent to  any  candidate  key  (i.e.,  the  closure  of  TXN_DTF  does 
not  equal  the  closure  of  any  candidate  key  for  any  record) . 
TXN_DTE  must  exist  as  part  of  some  key  (it  must  be  a  prime 
attribute)  and  the  only  key  that  could  assure  semantic  value 
would  be  the  key  created  by  the  entire  NFD  (i.e.,  the  inter- 
section record).  The  closure  of  CLNT_ID,STK_ABRV ,TXN_DTE  is 
checked  aqainst  closure  of  candidate  keys  for  all  records 
and   is    found    to   be   equivalent    to   RECORDS   in    Exhibit    3.4F   and 
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therefore  the  member  record.  If  RECORDS  did  not  exist  the 
NFD,  CLNT_ID,STK_ABRV  >>  TXN_DTE,  would  have  been  considered 
uninterpretable.  To  further  clarify  the  search  for  a  member 
record,    refer   to   the    graphic    models   in   Exhibit    4.20. 


Y)  I  II 

1    STK_ABRV         J »] 

I    CLNT_ID  |  | 

I I  I. 

OK 


I 


TXN    DTE 


z) 


I  I 

1    STK_ABRV         | » 

I     CLNT    ID  | 

i I 


STK_ABRV 
CLNT_ID 
TXN    DTE 


Exhibit    4.20 

Option  y  is  first  considered,  but  TXN_DTE  is  not  found  to  be 
a  candidate  key  of  any  record  in  Exhibit  3.4F. 
STK_ABRV,CLHT_ID,TXN_DTE  is  a  candidate  key  for  REC03D4  and, 
therefore,  represents  the  nember  record  as  shown  by  option 
z. 

4.  3.  2.  3.  3   Establish    Owner    Recor d 

The  LS  of  an  NFD,  unlike  the  RS,  does  not  necessarily 
identify  a  sinqle  record.  The  process  to  reduce  an  NFD's  LS 
to  an  exact  and  minimal  set  of  owners  uses  recursive  tree 
traversals.  Starting  with  the  entire  LS  as  a  potential  own- 
er record,  until  all  LSs  are  matched,  recursive  calls  gener- 
ate combinations   of      potential   key  attributes.        If      a   wrong 
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path  is  taken,  the  process  is  backed  up  to  where  the  initial 
combination  was  found  and  starts  aqain  at  that  point.  Based 
on  the  input  assertion  that  all  LSs  are  prime  attributes, 
this  tree  traversal  algorithm  should  eventually  find  a  set 
of  combinations  of  the  LS  attributes  whose  closures  are 
equal  to  the  closures  of  a  respective  set  of  records.  in 
exception  case  that  deserves  special  attention  exists  when  a 
set  of  LS  coabinations  evaluate  to  an  owner  record  that  is 
the  same  record  as  the  member.  This  type  of  relationship 
(i.e.,  an  Lii)  is  not  allowed  by  C0DA3YL  and,  when  respec- 
tive attribute  combinations  are  found  in  the  tree,  they  must 
be   bypassed. 

Consider   the   qraphic      depiction   of    STDCK_DB   and      NFD-G    in 
Exhibit  4.21    as   an  example   illustrating  this    procedure. 


RECORD  1 


|    stk-abrv  (key) 
|     stk-name 


REC0RD2 


J    clnt-id(key) 
I    clnt-name 


I          REC0RD3  | 

I I 

— »|    stk-abrv  (key)  |«- 
|    clnt-id  (key)     J 
|    stk-clnt-quan | 


NFD-G:       STK_ABRV,CLNT_ID    »    STK_CLNT_QUAN 
Exhibit    4.  2  1 
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From  NFD-G  [see  Exhibit  4.21)  two  sets  are  derived  by  the 
tree  traversal        algorithm.  The  LS        of  NFD-G, 

STK_ABRV,CLNT_ID,  initially  evaluates  to  the  same  record  as 
the  member  record  (i.e.,  SEC0RD3) .  Because  an  Lii  relation- 
ship is  not  allowed,  REC0RD3  is  bypassed  and  the  tree  trav- 
ersal algorithm  partitions  the  LS  into  STK_ABRV  and  CLNT_ID. 
STK_ABRV  is  a  candidate  key  of  EEC0ED1  and  therefore  an  own- 
er record.  CLNT_ID  is  a  candidate  key  of  REC0RD2  and  also 
an   owner  record. 

4.3.2.4   Create  get    Entities    in   User^s    Data   Base 

Once  owner  and  member  records  are  determined,  the  1:many 
sets  are  created.  A  pass  of  the  FDs  is  made  to  determine  if 
LS  and  RS  closures  are  equivalent  to  candidate  key  closures 
of  separate  records.  If  so,  a  1-to- 1  relationship,  such  as 
SETS  of  Exhibit  4.22,  is  created.  The  conceptual  schema  in 
Exhibit  4.22  shows  the  outcome  of  DB_INIT  for  the  Wampum 
Brokerage    case   study   in   terms  of   its   major  entities. 
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RECORD  1  J 

stk-abrv  (key  1)  | 
stk-name  (key2)  | 
rcnt-qut  l«- 
rcnt-vol  | 
stk-last-updtej 
tot-amt-wh.. .  | 
tot-num-wh. . .  | 
I 


SET1 


1 


REC0RD2 


SET3 


I 


REC0RD3  J 

|    stk-abrv (keyH 

»|    clnt-id    (key)  | 

SET2  |    stk-clnt-quanl 

]    stk-clnt-5S        I 

I I 

I 
I 
I 
SET4 
] 


-»l__ 


REC0RD4 


J. 


I  clnt-id    (key) 

I  clnt-name 

-|  emplr-name 

I  anul-slry 


I    stk_abrv(k  ey) 
-»|    clnt-id  (key) 
|    txn-dte (key 
|    brkr-tecEnd 
J    clnt-stk-txn$ 
|    f-stk-clnt-pur 


I 

SET5 
1 
I 

V 

REC0RD5 

emplr-name 

(key) 
emplr-ph 


Exhibit    4.22 

4.4   Status   of   flsexls   Data    Base   Schema 

At  this  point  in  the  desiqn  process,  the  leta  data  base 
may  contain  some  sets  which  still  need  to  be  modified  to  fit 
within  the  constraints  of  the  CODASYL  model.  For  instance, 
in  Exhibit  4.22  the  complex  relationship  between  RECORD!  and 
REC0RD2  (an  N-to-M  relationship)  is  not  acceptable.  The 
changes   which   still   must    be     made  are   accomplished   usinq   the 
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next  system  module  (DB_CUST)  .  These  modifications  are  post- 
poned until  the  schema  is  to  be  created.  The  next  chapter 
shows  how  these  recently  created  entities  can  be  customized 
to  meet  user  requirements  in  a  better  way. 


67 


Chapter   5 


DATA    BASE   CUSTOMIZATION 


It  is  unlikely  that  all  entities  created  by  DB_INIT  cor- 
rectly and  completely  describe  user  needs.  DB_INIT  makes 
several  assumptions  that  can  lead  to  incorrect  or  ineffi- 
cient code.  For  example,  the  defaulting  of  a  data  element's 
type  is  likely  to  be  wrong  as  often  as  right.  Therefore  the 
need  exists  to  modify  entities  to  model  the  users'  domain 
more  correctly.  The  data  base  customization  module 
{DB_CUST)  is  designed  to  lead  the  data  base  designer  easily 
through  the  processes  of  adding,  deleting  and  changing  char- 
acteristics of  the  data  elements,  records,  and  sets  created 
by  DB_INIT.  DB_CUST  meets  these  reguirements  through  the 
following    services: 

1)  modification    of   all   entities    via   a   user-friend- 
ly,   menu-driven,   interactive    system, 

2)  data   base   design    assistance   when   the   user    is    in 
doubt   about   available    options,    and 

3)  real-time   conflict   checks   on   all  applicable   en- 
tries. 

The  current  assumed  status,  with  respect  to  the  data  base 
design  process,  is  that  a  data  base  has  just  been  initial- 
ized and  is  ready  for  customization  as  shown  in  Exhibit 
1.22. 
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5.  1  Establish   Position   in   DB-GEN 

Selections   2-5  of    of   the    primary    menu  in   Exhibit   5.1    com- 
prise   the    options   available  in    DB  COST. 


**    PRIMARY 

MEND 

** 

1       1) 

DATA    BASE    INITIALIZATION 

1            2) 

DATA    ELEMENT    DPDATE 

1            3) 
J            <•) 

RECORD    UPDATE 
SET    DPDATE 

1            5) 

DATA    BASE    UPDATE 

1           b) 

PRINT    DATA 

1           7) 

CREATE    SCHEMA 

1            X) 

EXIT 

1            ==> 

1            2 

1 





__ 

—     , 

J 

Exhibit  5.  1 

As  described  in  earlier  chapters,  there  can  be  an  undet- 
ermined number  of  meta  data  bases  under  DB_GEN.  Substantial 
effort  has  been  made  to  keep  each  of  the  data  base's  enti- 
ties separate  so  like- named  entities  of  one  data  base  can 
exist  and  be  manipulated  without  affecting  those  of  another 
data  base.  Although  difficult  to  implement  and  costly  in 
terms  of  input-output  reguests,  meta  data  base  separation  is 
a  necessity  for  integrity  purposes. 

5.  2  Data  Base  Update 

Through  selection  five,  DATA  BASE  UPDATE  (see  Exhibit 
5.1),  the  data  base  name  can  be  chanqed  with  full  confidence 
that  all  subordinate  entities  will  remain  intact.    The  data 
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base  name  is  the  only  required  attribute  of  the  DATA  BASE 
record.  Available,  but  not  required,  is  the  ability  to  as- 
sign a  data  base  administrator  to  each  Beta  data  base.  Once 
a  meta  data  base  has  been  established,  there  is  little  need 
for   the   DATA    BASE   UPDATE   nodule. 

5. 3  Data  Element    Update 

Data  elements  form  the  basic  building  blocks  for  any  data 
base.  Evident  from  Chapter  4,  Data  Base  Initialization  and 
Interpretation,  is  the  fact  that  data  base  generation  is  ac- 
complished only  from  knowledge  of  how  data  elements  relate 
to  one  another.  Although  much  can  be  told  about  a  data  ele- 
ment, DB_GEH  requests  only  the  most  basic  data  element  in- 
formation required  for  the  schema  generation  {i.e.,  name, 
definition,    type,   and   format)  . 

The  conceptual  schema  in  Exhibit  2.1  illustrates  how  a 
data  element  participates  with  other  data  base  entities. 
The  CONCATENATED-BY  relationship  of  DATA  ELEMENT  onto  it- 
self, allows  for  group-level  data  elements  (a  data  element 
comprised  of  sub-elements) .  Group  level  data  elements  can- 
not be  described  in  terms  of  functional  dependencies,  there- 
fore, they  must  be  described  using  the  customization  module. 
The  SBOUPED_IN  and  POP0LATED_WITH  relationships  are  initial- 
ly created  by  DB_INIT  and  remain  for  use  in  this  schema  un- 
less removed  throuqh  use  of  the  RECOE D_UPDATE  module.  A  se- 
lected  few   of   the   data   elements   are  customized,      avoiding  an 
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exhaustive  trace  of  data  element  customization  for  the  en- 
tire organization  which  is  not  appropriate  for  this  study. 
Selection  two  of  the  primary  menu,  DATA  ELEMENT  UPDATE  (see 
Exhibit  5.  1)  ,  lists  all  the  data  elements  created  by  DB_INIT 
(see   Exhibit    5.  2)  , 


**    DATA    ELEMENT    UPDATE    ** 


1) 

CREATE    ELEMENT 

16) 

2) 

ANUL-SLRY 

17) 

3) 

BRKE-RECMND 

18) 

») 

CLNT-ID 

19) 

5) 

CLNT-NAME 

X) 

6J 

CLNT-STK-PHCNT-I 

7) 

CLNT-STK-QUAN 

8) 

CLNT-STK-TXN-PRC 

9) 

EMPLR-PH 

10) 

EMPLR-NAME 

11) 

NDM-STK-CLNT-PUR 

12) 

RCNT-QUT 

13) 

RCNT-VOL 

!«) 

STK-ABRV 

15) 

STK-LAST-UPDTE 

MAKE 
fc 

SELECTION    ===> 

STK-NAME 

TOT-AMT-WHEN-REC 

TOT-NUM-HHEN-REC 

TXN-DTE 

EXIT 


Exhibit    5.2 

Each  of  the  four  maior  data  base  entities  use  the  same 
format  for  presentation  of  the  entities  of  concern.  The 
services  available  from  Exhibit    5.2   are; 

1)  the   creation    of   a    new   entity    (selection    1)  , 

2)  the   updating   of   existing  entities     (valid   selec- 
tion  other   than   "1"    or   "X")  ,    and 

3)  the   removal   of   an    existing   entity     (selection    of 
an    existing   entity    followed    by    "DELETE"). 
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This  menu  system  provides  a  comprehensive  approach  for  enti- 
ty maintenance;  however,  several  shortcuts  have  been  created 
to  reduce  menu  traversals  and  therefore  increase  machine  and 
manpower  performance.  For  example,  the  data  base  designer 
can  assign  a  data  element  name  to  a  newly  created  data  ele- 
ment by  enterinq  the  data  element  name  following  menu  number 
"1"  in    Exhibit    5.2. 

Data  element  customization  might  begin  by  renaming  selec- 
tion six  of  Exhibit  5.2.  Truncation  by  DB_INIT  has  left 
that  name  less  than  descriptive.  Exhibits  5.3  and  5.  <4  track, 
the   name  changing    process. 


I                **    CHANGE    OS    DELETE    DATA    ELEMENT    ** 

|     1)     ELEMENT    NAME:    CLNT-STK-PRCNT-I 

1     2)     DEFINITION: 

I     3)     TYPE:    CHAHACTEH 

I     4)     TOTAL    SIZE:     010 

]     X)     EXIT 

]     MAKE    SELECTION    ===> 

J     1CLNT-STK-INVST 

Exhibit   5.3 
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I 

]  **    CHANGE    OS    DELETE    DATA    ELEMENT    ** 

J 

J  1)     ELEMENT    NAME:    CLNT-STK-INVST 

]  2)     DEFINITION: 

)  3)     TYPE:    CHARACTER 

i  4)     TOTAL    SIZE:     010 

J  X)     EXIT 

I 

I  MAKE    SELECTION    ===> 

|  3numeric 

I 


Exhibit    5.4 

Suppose  the  TYPE  attribute  of  CLNT_STK_INVST  needs  to  be 
modified  from  CHARACTER  to  NUMERIC  and  given  an  applicable 
format.  Exhibits  5.4-5.6  illustrate  the  process  the  data 
base  designer  must  use  to  accomplish  this  task.  In  Exhibit 
5.4  a  menu  number  of  three  followed  by  a  menu  entry  of  "nu- 
neric",  indicates  the  TYPE  attribute  is  to  be  modified  from 
CHARACTER    to    NUMERIC   as    shown    in    Exhibit   5.5.  Exhibit    5.5, 

inturn,  changes  the  TOTAL  SIZE  attribute  from  ten  to  three 
(see   Exhibit    5. fc) . 


**   CHANGE    OR    DELETE    DATA    ELEMENT    ** 

1)  ELEMENT    NAME:    CLNT-STK-INVST 

2)  DEFINITION: 

3)  TYPE:    NUMERIC 

4)  TOTAL    SIZE:     010 

5)  FRACTION   SIZE:    0 
X)  EXIT 

MAKE    SELECTION    ===> 
4    3 


Exhibit    5.5 
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**    CHANGE    OR    DELETE    DATA    ELEMENT    ** 


1)  ELEMENT    NAME:    C1NT-STK-IN VST 

2)  DEFINITION: 

3)  TYPE:  NUMERIC 

4)  TOTAL  SIZE:  003 

5)  FRACTION  SIZE:  0 
I)  EXIT 

MAKE  SELECTION  ===> 
x 


Exhibit  5.6 

To  illustrate  other  features,  let  us  assume  that  a  user  has 
requested  additional  information  which  requires 

STK_LAST_UPDTE  to  be  partitioned  into  STK_DAY_UPDTE  and 
STK_TIMS_UPDTE.  These  sub-elements  have  been  created  and 
appear   in   exhibits   5.7   and   5.8.  The   two   new   data   elements 

must  be  created  before  STK_LAST_DPDTE  could  add  these  as 
sub-elements.  If      an        attempt      were        made      to        divide 

STK_LAST_0PDTE  into  sub-elements  prior  to  their  creation,  an 
error  message  would  be  displayed  and  a  list  of  all  valid 
data   elements   would   be   made  available.  The   addinq   of   sub- 

elements  is  accomplished  by  entering  menu  number  four  fol- 
lowed by  the  sub-element  name  (see  Exhibit  5.9).  If  the 
data  base  designer  is  not  sure  of  the  sub-element  to  be  add- 
ed, the  menu  entry  can  be  left  blank  and  a  list  of  existing 
data   elements   appears   for   selection. 
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**      CB.EATE    NEW    DATA 

ELEMENT       **                                                                 i 

1)     ELEMENT    NAME:    STK- 

-TIME- 

-UPDTE                                                                        | 

2)     DEFINITION: 

3)    TYPE:    NUMERIC 

«)    TOTAL    SIZE:    006 

5)     FRACTION    SIZE:     0 

X)     EXIT 

MAKE    SELECTION    ===> 

j 

Exhibit    5.7 


**       CREATE    NEB    DATA    ELEMENT 

** 

I  1) 

1    2) 
1     3) 
1     ») 
i     5) 
1     X) 

ELEMENT    NAME:    STK-DAY-UPDTE 

DEFINITION: 

TYPE:     NUMERIC 

TOTAL    SIZE:     006 

FRACTION    SIZE:     0 

EXIT 

1     MAKE    SELECTION    ===> 

Exhibit    5.8 


] 

I  **    CHANGE    OR    DELETE    DATA    ELEMENT    ** 

I 

I  1)     ELEMENT    NAME:    STK-L AST-UPDTE 

I  2)     DEFINITION: 

|  3)     TYPE:    CONCATENATED 

I  «)     ADD    SOB    ELEMENT 

I  DELETE    SOB    ELEMENT    .     .     . 

I  5)     STK-DAY-OPDTE 

I  6)     STK-TIME-OPDTE 

I  X)     EXIT 

I 

I  MAKE    SELECTION    === > 

i 


Exhibit    5.9 
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5.  U   Record  fiEdate 

Similar  to  DATA  ELEMENT,  the  RECORD  entity  is  very  tight- 
ly coupled  within  the  DB_GEN  data  base  (see  Exhibit  2.1). 
Populated  with  data  elements  and  linked  to  sets  for  which  it 
is  the  owner  and/or  member,  RECORD  functions  as  an  interface 
entity  for  the  data  base.  Upon  entry  into  the  RECORD_npDATE 
nodule,  the  need  to  clarify  the  generic  record  names  is  most 
apparent  (see  Exhibit  5.10).  Changing  RECORD  attributes,  as 
one  might  suspect,  is  similar  to  DATA  ELEMENT  attribute 
changes.  Selection  of  a  record  displays  the  defaulted  re- 
cord attributes  and,  most  importantly,  the  data  elements 
linked  to  that  record  by  DB_INIT  (see  Exhibit  5.11).  By 
viewing  the  data  elements  within  a  record  a  more  descriptive 
record   name   can    likely    be   created    (see   Exhibit    5.12). 


**  RECORD  UPDATE  ** 

I           1) 

CREATE  RECORD 

| 

1       2) 

RECORD  1 

1        3) 

RECORD2 

J 

1        t) 

RECORD3 

1       5) 

RECORD4 

1       6) 

RECORD5 

1        X) 

EXIT 

1        MAK 

E  SELECTION  ===> 

| 

I       3 

Exhibit      5.10 
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**  CHANGE  OH  DELETE  RECORD  ** 

1)  RECORD  NAME:  RECORD3 

2)  RECORD  LOCATION  BODE:  CALC 

3)  RECORD  DUPLICATE  OPTION:  DN 

4)  RECORD  CALC  KEY  OH  VIA  SET: 

5)  ADD  DATA  ELEMENT  TO  REC0RD3 
DELETE  DATA  ELEMENT  ... 

6)  CLNT-STK-INVST 

7)  CLNT-STK-QOAN 

8)  CLNT-ID 

9)  STK-ABRV 
X)  EXIT 

MAKE    SELECTION    ===> 
1    STK-CLNT 


Exhibit       5.11 


**  RECORD  UPDATE  ** 

1)  CREATE  RECORD 

2)  CLIENT 

3)  EMPLR 

4)  STK-CLNT 

5)  STK-CLNT-TXN 

6)  STOCK 
X)  EXIT 


MAKE    SELECTION    ==> 


Exhibit      5.  12 
The  record   attribute      of   most    concern   is      the   LOCATION    BODE. 
Assignment    of   this  attribute   directly   influences   the   remain- 
ing  two   attributes    (i.e.,       the    DUPLICATE   OPTION    and   CALC    KEY 
OR   VIA   SET).  IB   Exhibit    5.13    STK_NAME   has      been    chosen   as 

the  direct  access  key.  (Note:  If  one  wanted  a  concatenated 
CALC  key,  it  would  be  necessary  to  create  such  an  element 
using    DATA    ELEMENT      UPDATE.         Only   one    data      element    name   is 
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accepted  as  a  CALC  key.)  A  change  of  the  LOCATION  MODE  from 
CALC  to  VIA  is  Bade. in  Exhibit  5.13  and  5.1U.  This  change 
forces  suppression  of  the  no  longer  applicable  DUPLICATE 
OPTION.  Exhibit  5. 11  illustrates  entry  of  an  erroneous  set 
for  the  VIA  SET  parameter  (STK_CLNT  must  be  a  member  record 
in  the  set  chosen.)  Selection  of  an  invalid  set  name  for 
VIA  SET  results  in  an  error  message  followed  by  a  help  fea- 
ture which  lists  the  set  in  which  STK-CLNT  functions  as  a 
member   record    (see  Exhibit   5.  15)  . 


1                **    CHANGE    OR    DELETE    RECOHD    ** 

]             1)     RECORD    NAHE:     STK-CLNT 

1             2)     RECORD    LOCATION    BODE:    CALC 

J             3)     RECOHD    DUPLICATE    OPTION:     DN 

|             4)     RECORD    CALC    KEY    OS    VIA    SET:    STK-NAME 

i             5)     ADD    DATA    ELEMENT    TO    RECORD3 

|             DELETE    DATA    ELEMENT    .     .     . 

1                        6)     CLNT-STK-INVST 

]                        7)     CLNT-STK-QnAN 

I                        8)     CLNT-ID 

I                        9)     STK-ABRV 

J             X)     EXIT 

I             BAKE    SELECTION    ===> 

1             2    VIA 

Exhibit      5.13 
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**  CHANGE  OB  DELETE  RECORD  ** 

1)  RECORD    NAME:     STK-CLNT 

2)  RECORD    LOCATION    MODE:    VIA 

3)  RECORD  CALC  KEY  OR  VIA  SET: 
U)  ADD  DATA  ELEMENT  TO  RECORD3 
DELETE    DATA    ELEMENT    .     .     . 

5)  CLNT-STK-INVST 

6)  CLNT-STK-QUAN 

7)  CLNT-ID 

8)  STK-ABRV 
X)  EXIT 

MAKE    SELECTION    ===> 
3    SET3 


Exhibit       5.  14 


1                          **    SELECT    VIA    SET    ** 

]          1)        SET2 
1          X)       EXIT 

1         =  =  >    1 

Exhibit      5.15 

Additional  RECORD  UPDATE  capabilities  are  shown  by  con- 
ducting a  common  data  base  optimization.  To  include  a  stand 
alone  1-to-1  relationship  into  its  owner  record  is  often  a 
good  tradeoff  of  increased  redundancy  for  improved  efficien- 
cy. This  type  of  relationship  exists  between  CLIENT  and 
EMPLR  in  the  Wampum  Brokerage  system  (see  Exhibit  4.22). 
The  EMPLR  record  is  deleted  from  the  data  base  (see  Exhibit 
5.16)  and  EflPLR_PH  is  linked  to  the  CLIENT  record  (see  Ex- 
hibit   5.17    -    5.18).       EMPLH_NAME    previously    existed   in    CLIENT 
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as   a   foreign      key   so   it    was   not    necessary      to   add   EMPLP_NAME 
to   CLIENT. 


J                                   **    RECORD    UPDATE    ** 

J           1)        CREATE    RECORD 

I          2)        CLIENT 

1          3)        EMPLR 

1          U)       STK-CLNT 

I          5)        STK-CLNT-TXN 

I          6)        STOCK 

I          X)        EXIT 

]          HAKE    SELECTION    ===> 

j 

I          3       DELETE 

Exhibit      5.16 


**    CHANGE    Ofi   DELETE    RECORD    **                             | 

I       1) 

RECORD    NAME:     CLIENT                                                              | 

1           2) 

RECORD    LOCATION    MODE:    CALC                                           | 

1           3) 

RECORD    DUPLICATE    OPTION:     DN                                        | 

J          "0 

RECORD    CALC    KEY    OR    VIA    SET:    CLNT-NAME             | 

J           5) 

ADD    DATA    ELEMENT    TO    CLIENT                                           | 

|            DELETE    DATA    ELEMENT    ...                                                       1 

6)     ANUL-SLRY                                                                               | 

7)     EMPLR-NAME                                                                            | 

8)     CLNT-NAME                                                                              | 

9)     CLNT-ID                                                                                    i 

1             X) 

EXIT                                                                                                       | 

]             HAKE    SELECTION    ===> 

|           5 

EMPLR-PH                                                                                               | 

Exhibit      5.  17 
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**  CHANGE  OE  DELETE  RECORD  ** 

1)  RECORD    NAME:     CLIENT 

2)  RECORD    LOCATION    MODE:    CALC 

3)  RECORD    DUPLICATE    OPTION:    DN 

4)  RECORD    CALC    KEY    OR    VIA    SET:    CLNT-NAME 

5)  ADD    DATA    ELEMENT    TO    CLIENT 
DELETE    DATA    ELEMENT    .     .    . 

6)  ANDL-SLRY 

7)  EMPLR-NAME 
3)  CLNT-NAME 
9)  CLNT-ID 

10)     EMPLR-PH 
X)     EXIT 

MAKE    SELECTION    ===> 


Exhibit    5.  18 

5. 5  Set  SEdate 

The  SET_UPDATE  module  uses  the  customization  software 
previously  discussed.  After  more  meaninqful  names  are  se- 
lected (see  Exhibit  5.19),  few  decisions  concerninq  a  set 
remain  due  to  the  fact  that  selections  2-5  are  derived  dur- 
ing  data   base   initialization     (see   Exhibit    5.2  0). 


1) 
2) 
3) 
*J 

5) 

X) 


**    SET    UPDATE    ** 

CREATE    SET 

OHNED-BY 

OBNS 

STK-CLNT-SET 

STK-CLNT-TXN-SET 

EXIT 


MAKE  SELECTION  ===> 
2 


Exhibit   5.19 
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**   CHANGE    OR    DELETE   SET    ** 

1       1) 

SET    NAME:       OHNED-BY 

1           2) 

SET    OH  NEE:       STOCK                                                                 | 

1           3) 

SET    MEMBER:       CLIENT                                                           J 

1           •) 

SET    VALUE:        1    TO    MANY                                                      | 

1            5) 

SET    INVERSE     VALDE:        1    TO    MAN!                                J 

1            6) 

SET    MEMBERSHIP:       MANDATORY    AUTOMATIC            | 

J            7) 

SET    ORDER:       FIRST                                                                 j 

1            X) 

EXIT                                                                                                    | 

Exhibit      5.2  0 

Any  changes  made  to  OWNER  or  MEMBER  set  attributes  are 
verified  by  DB_C0ST  to  assure  that  the  the  owner  and  member 
records  that  are  selected  exist  and  are  disjoint  (remember 
Lii  sets  are  not  allowed) .  If  a  set  was  established  by  an 
NFD,  the  SET  VALUE  is  1-to-Many  and  if  it  was  derived  from 
an      FD      its   SET      VALUE      is       1-to~1.  The    SET      INVERSE      for 

1-to-Many  SET  VALUE  is  assumed  1-to-1  unless  one  or  both  of 
the  following   are   true: 

1)  The  closure  of  the  concatenation  of  owner  and 
member  candidate  keys  is  equal  to  the  closure 
of  another  record  (i.e.,  an  intersection  record 
exists    between    the    owner  and    member   records). 

2)  At  least  one  other  record  exists  that  has  the 
opposite  relationship  of  owner  and  member  re- 
cords of  the  set  in  question  (i.e.,  an  M-to-N 
relationship   exists)  . 

The  SET  INVERSE  for  a  set  with  a  SET  VALUE  of  1-to-1  is  as- 
sumed to  be  1-to-Many.  Otherwise,  the  member  and  owner  re- 
cords   are   the   same. 
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Possibly   the      most   mystifying   of      all  IDMS      parameters   is 
SET   MEMBERSHIP.  To    help      offset    the      perplexities    of      SET 

MEMBERSHIP,  excerpts  from  an  IDMS  programmer's  guide 
(CADY80)  supplement  the  SET  MEMBERSHIP  help  feature  (see  Ex- 
hibit   5.21). 


**    SET    MEMBERSHIP    VALUES    ** 

1)  MAHDATORY    AUTOMATIC    — 

DISCOS RECTI OS  FROM  SET  ONLY  BY  ERASING  RECORD 
CONNECTION  TO  SET  AUTOMATIC  WHEN  STORED 

2)  MANDATORY    MANUAL    - 

DISCONNECTION  FROM  SET  ONLY  BY  ERASING  RECORD 
CONNECTION  TO  SET  VIA  "CONNECT"  STATEMENT 

3)  OPTIONAL    AUTOMATIC    - 

DISCONNECTION    FROM    SET    VIA    "DISCONNECT"    STATEMENT 
CONNECTION    TO    SET    AUTOMATIC    WHEN    STORED 

4)  OPTIONAL    MANUAL    - 

DISCONNECTION    FROM    SET    VIA    "DISCONNECT"    STATEMENT 
CONNECTION    TO    SET    VIA    "CONNECT"    STATEMENT 

X)       EXIT 


Exhibit      5.21 

With  respect  to  SET  ORDER,  a  final  series  of  menu  traver- 
sals  graphically  summarizes  DB_CUST's  capabilities.  Exhibit 
5.22  illustrates  a  user's  reguest  for  the  SET  ORDER  option. 
A  selection  of  ASCENDING  {see  Exhibit  5.23)  causes  the  "** 
CHANGE  OR  DELETE  SET  **"  display  to  add  the  SORT  ELEMENT  op- 
tion (see  Exhibit  5.  24) .  A  sort  field  must  be  a  data  ele- 
ment   present   in    the   member   record.         In   the   likely   event    one 
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can  not  remember  the  spelling  for  the  sort  field  data  ele- 
ment, the  help  feature  lists  all  possible  options  (see  Ex- 
hibit   5.25). 


1              ** 

CHANGE    OB    DELETE    SET    ** 

1       1) 

SET    NAME.:       OWNED-BY 

1           2) 

SET    OHNEB:        STOCK 

1           3) 

SET    MEMBER:       CLIENT 

J           ») 

SET    VALUE:        1    TO    MANY 

1            5) 

SET    INVERSE    VALUE:        1    TO 

MANY 

J            fc) 

SET    MEMBEPSHIP:        MANDATORY    AUTOMATIC            ] 

1            7) 

SET    OBDEB:       FIRST 

J            X) 

EXIT 

I            === 

=  > 

|            7 

I 

Exhibit   5.22 


**  SET  ORDER  VALUES  ** 


1) 

FIRST 

2) 

LAST 

3) 

NEXT 

<*) 

PRIOR 

5) 

ASCENDING 

e) 

DESCENDING 

X) 

EXIT 

Exhibit   5.23 
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**   CHANGE    OR    DELETE    SET    **                                   ! 

1) 

SET    NAME:       OWNED-BY 

2) 

SET    OHNER:       STOCK 

1 

3) 

SET    MEMBER:       CLIENT 

») 

SET    VALUE:       1     TO    MANY 

5) 

SET    INVERSE    VALUE:       1 

TO    MANY                             1 

6) 

SET    MEMBERSHIP:       MANDATORY    AUTOMATIC          i 

7) 

SET    ORDER:       ASCENDING 

8) 

SET    SORT    ELEMENT: 

9) 

SET    DUPLICATE    OPTION: 

DUPLICATES    NO         ) 

X) 

EXIT 

1 

8 

> 

J 

Exhibit   5.2« 


**  SELECT  SORT  ELEMENT  ** 

1)  CLNT-ID 

2)  CLNT-NAME 

3)  ANUL-SLRY 

4)  EHPLB-NAME 

5)  EMPLR-PH 
X)  EXIT 

MAKE    SELECTION    ===> 


Exhibit      5.25 


5. fc  Data  Base  Customization  as   a    Maintenance    Aid 


Once  the  data  base  administrator  feels  confident  that  the 
data  base  entities  have  been  properly  customized,  it  is  time 
to  create  the  schema.  It  is  likely  however,  that  the  first 
few  attempts  at  schema  creation  will  find  missinq  data  or 
unforeseen  conflicts.  These  problems,  in  conjunction  with 
requirement   chanqes,    may   cause   several   revisits   to  DB_CUST. 
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Chapter    6 


SCHEMA    CKEATION 


Upon  entry  of  the  user's  data  base  name,  the  initial  menu 
entry  of  the  system,  edit  checks  and  minor  enhancements  are 
performed  to  insure  a  clean  IDHS  schema  compilation.  Vali- 
dation and  conflict  checking  continue  throughout  the  data 
base  initialization  and  customization  process,  thus  assuring 
many  strong  input  assertions  for  the  actual  creation  of  the 
IDHS  schema.  Therefore,  SCHEHA_CREATE,  the  module  that  cre- 
ates schema  source  code,  does  not  require  user  interaction 
to  reformat  entities  into  IDHS  data  definition  statements. 
Of   most   interest   is   the   way  SCHEHA_CHEATE: 

1)  simplifies  M-to-N  relationships  to  meet  CODASiL 
(and   IDHS)    requirements, 

2)  generates  pointer  positions  within  records  by 
simulating  the  IDHS  "clock  rule"  algorithm 
(PEEE77)  ,    and 

3)  establishes  l-to-1  relationships  via  owner 
pointers   and   foreign    keys. 

6.  1   Check    for   pissing  Data 

Before  addressing  the  actual  schema  creation,  a  missing 
data  sub-module  (HISSING_DATA_CHECK)  must  be  successfully 
run.      This    module   only   delineates  required    missing   data.      If 
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missing   data   is   detected,    the   data   base  administrator   is   no- 
tified   (see  Exhibit   fc.  1)    and    schema   compilation   is   aborted. 


***    REQUIRED    BUT    MISSING    DATA    *** 

DATA    ELEMENT:  ATTRIBUTE: 

STK_ABRV  FORMAT 

STK_CLNT_QUAN  TYPE 

RECORDS: 

CLIENT  CALC   KEY 

STK_CLNT_TXI!  VIA   SET 

SET: 

OWNED_BY  SET    MEMBERSHIP 


Exhibit    6. 1 
6.2   Verify   E.ntit;y.    Customization 

After  missinq  data  requirements  are  met  throuqh  the  use 
of  DB_CUST,  a  scan  of  all  entities  is  made  to  verify  custom- 
ization. As  discussed  in  Chapter  5,  Data  Base  customiza- 
tion, nearly  all  entities  require  some  customization.  Un- 
like the  missing  data  check,  this  routine  generates  only 
warning  messaqes  (see  Exhibit  t.2)  and  then  continues  to  the 
next    process. 


***    WARNING — ENTITIES    NOT    CUSTOMIZED    *** 
DATA    ELEMENT:  RECORD:  SET 


STK_NAME  RECORD3  SET« 

CLIENT    NAME 


Exhibit    fc.2 
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6.3  Simplify.  Complex  Relationships 

Complex  relationships  (B-to-N  relationships)  are  banned 
by  CODASYL  data  base  management  system  specifications.  The 
user-required  sets  from  the  Wampum  Brokeraqe  System  repre- 
sent such  a  relationship,  (see  Exhibit  6.3). 

owned-by        

I  | »,      ", 

I       STOCK       1  owns  ]     CLIENT     | 

I l« 1 I 

Exhibit  6.3 
In  all  situations  the  solution  lies  in  the  creation  of  an 
intersection  record  (see  Exhibit  fc.4).  The  system  automati- 
cally detects  this  situation  by  evaluating  SET  VALUE  and  SET 
INVERSE  VALUE  attributes  of  a  set  entity  and  creates  the 
necessary  intersection  record  and  accompanying  sets. 


11  11 

I       STOCK       |  J    CLIENT       | 

I 1  1 I 

I  I 

owned-by owns 

I  I  1  I 

»|     STK_CLNT       |« 

1 I 

Exhibit  6.1 
Traversals  from  STOCK  to  CLIENT  are   now  made  by  the  follow- 
ing statements: 

OBTAIN  NEXT  SET  (OWNED_BY)  ; 
OBTAIN  OWNER  SET  (OWNS)  ; 
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From  CLIENT  to  STOCK  just  the  opposite  statements  are  re- 
quired. 

OBTAIN    NEXT    SET  (OWNS)  ; 
OBTAIN    OWNER    SET  (OWNED_BY)  : 

Overtly,  the  solution  seems  flawless.  But,  if  the  user  re- 
quires other  services  additional  sets  made  be  needed.  For 
example,  perhaps  a  CLIENT  wishes  to  know  which  of  his  stocks 
have   made   the   most   money    (see    Exhibit    6.5). 

owns  

|« | 

J         owned-by  | 

STOCK  | »]  CLIENT 

I    made-money-on    | 


Exhibit  6.5 
Sets  OWNS  and  OWNED-BY  address  reciprocatinq  questions,  are 
correctly  modeled  by  Exhibit  6.  H,  and  can  be  easily  imple- 
mented. However,  given  the  existence  of  the  OWNS  and 
OWNED-BY  sets,  the  implementation  of  the  MA DE-MONEY-ON  set 
is  less  apparent.  If  a  second  intersection  record  were  cre- 
ated, software  could  not  distinguish  reciprocatinq  relation- 
ships like  OWNS  and  OWNED-BY  from  non-reciprocatinq  rela- 
tionships like  OWNED-BY  and  MADE-KONEY-ON-  When  multiple 
sets  exist  between  records,  the  interpretation  of  these  sets 
traditionally  require  human  input.  However,  by  aqain  refer- 
rinq  to  Bernstein's  research  (BEBN76)  ,  a  different  approach 
provides  a  solution  to  this  problem  without  human  interven- 
tion. 
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Recall  from  Chapter  3,  Bernstein's  Algorithm  and  User  Re- 
quirements, that  each  of  Bernstein's  NFDs  are  converted  to 
FDs  by  concatenating  on  the  LS  both  the  BS  and  LS  attributes 
and  creating  a  new  SS  ,  namely  a  unique  theta  attribute. 
Each  theta  represents  a  set  and  the  value  of  theta  (either 
"yes"  or  "no")  indicates  an  association  between  current  re- 
cords. This  concept,  applied  to  a  network  model,  limits  in- 
tersection records  to  one,  and  set  names  become  data  ele- 
ments   within   the   intersection    record    {see    Exhibit    6-6). 


I  I 

I       STOCK       | 


stock-client-0 1 

i       |  STK_CLNT 

I  owns 

I  owned-by 

J  made-$-on 


I  I 

I     CLIENT       | 

I I 

I 

I 

client-stock -0  2 

I 


« 


Exhibit  6.6 
This  simplification  technique  provides  a  consistent  and  use- 
ful method  for  solvinq  H-to-N  relationships,  and  by  usinq 
IDMS'  "logical  record  facility",  traversals  remain  quite 
readable.  For  example,  a  traversal  from  STOCK  to  CLIENT 
would    read 

OBTAIN    NEXT    SET  (STOCK_CLIENT_0 1 )     WHEBE     [OWNS    =    'YES'); 
OBTAIN    OWNER    SET  (CLIENT_STOCK_02)  ; 

Should  the  data  base  administrator  find  substantial  diffi- 
culties with  this  transformation,  any  type  of  record/sot 
configuration  can   be   created    via    DB   CtJST. 
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fc . t  Establish    1-to-1    Relationships 

The  implementation  of  a  1-to-1  relationship  is  analogous 
to  a  traditional  table  lookup  operation.  Use  of  an  IDMS  set 
for  this  type  of  relationship  is  poor  use  of  the  software. 
A  set  (and  all  its  pointers)  should  not  be  introduced  if  at 
most  there  is  to  be  one  occurrence  of  the  member  record.  If 
an  inverse  relationship  exists,  there  is  no  problem;  the 
owner  pointer  provides  the  needed  relationship.  If  the  in- 
verse relationship  is  non-existent,  SCHEHA_CREATOK  adds  a 
member  record  candidate  key  to  the  owning  record,  providing 
it  does  not  already  exist  (see  Exhibit  6.7).  The  1-to-1  re- 
lationship can  now  be  accomplished  by  matchinq  like-keys 
(see    EMPLR_NAME    in    Exhibit    6.7). 


I       CLIENT      J 
, 1 

I             •  1 

I           :  I 

J  EMPLR-  | 

I  NAME  | 


1          EMPLR       J 
J | 

I  •  ] 

I  :  I 

J       EMPLR-       1 
I       NAME  | 

)  (CA1C    KEY)  | 
I I 

Exhibit    fc.7 
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6. 5  Generate  Set  Pointers 

IDHS  establishes  pointers  within  records  by  a  peculiar 
technique  known  as  the  "clock  rule"  (PERR77)  .  Exhibit  6.8 
graphically  presents  each  record  of  the  Wampum  Brokeraqe 
conceptual  schema  spiraled  twice  in  their  12  hour  clocks. 


I  next  -  1 
I  prior  -  2 
i 

STOCK-CLIENT-01 


next    -   4 
prior  -    5 
owner   -   6 


CLIENT-STOCK-02 
I 
I 


next  -  1 
prior  -  2 
owner  -  3 


STK-CLNT-TXN-SET 


next  -  1 
prior  -  2 
owner  -  3 


Exhibit  t 
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Starting  at  top  center  (12  o'clock),  circle  the  graphical 
representation  of  a  record  twice  in  a  clockwise  direction. 
On  the  A.M.  spiral,  assign  pointer  positions  for  all  sets  in 
which  the  record  participates  as  a  member  in  the  order  the 
sets  are  encountered.  On  the  P.M.  spiral,  assign  pointer 
positions  for  all  sets  in  which  the  record  participates  as 
an    owner  in   the   order   the   sets    are   encountered. 

SCHEMA_CREATE    simulates    the    clock      rule    algorithm    in    much 

the  same   way   it   is  done   graphically.      Possibly   the   best    form 

of   explanation    is   a   high    level   algorithm    (see   Exhibit    t.9). 

DECLARE    tables — member-next-pointer,    member-prior-pointer, 
member-owner- pointer,  owner-next -pointer, 
owner-prior -pointer 

BEGIN    ALGORITHM; 

FOR   EACH    record    DO; 

initialize   pointer  to   1; 

FDR    EACH  set   DO;      /**  simulates   a. m.    spiral   **/ 

IF  member    of   current   set    =    current   record 

/**   comment   -   assign   member   record   pointers    **/ 
member-next-pointer    (current  set)    <--   pointer; 
member-prior-pointer    (current   set)    < —    pointer   +    1; 
member-owr.er-pointer    (current  set)    < —   pointer    +    2; 
increment   pointer  by   3; 

END   IF; 

END    LOOP; 

FOR    EACH  set   DO;      /**  simulates   p.m.    spiral   **/ 

IF  owner   of    current   set    =   current   record 

/**  comment — assign   owner   record   pointers   **/ 
owner-next-pointer    (current   set)    < —   pointer; 
owner-prior -pointer    (current   set)    < —    pointer   +    1; 
increment    pointer  by  2; 

END   IF; 

END    LOOP; 
END    LOOP; 
END    ALGORITHM; 

Exhibit    fc.9 
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A  detailed  narrative  explanation  of  the  above  algorithm 
would  only  serve  to  distort  its  clarity.  In  brief,  the  two 
inner  loops  simulate  the  member  record  and  owner  record 
pointer  assignments  for  each  record  represented  by  the  outer 
loop.  The      alqorithm  establishes      all      possible      pointers 

(i.e.,  next,  prior,  and  owner)  .  Although  this  default  op- 
tion lacks  praise  for  storage  efficiency,  there  need  not  be 
any  concern  by  the  programmer  about  the  existence  of  a 
pointer  or  any  need  for  the  data  base  administrator  to  per- 
form a  possibly  costly  regeneration  of  an  operational  system 
due  to   additional   pointer    requirements. 

6 . 6  Create  Data   Definition  3 ta te me n ts 

The  remaining  function  of  SCHEMA_CREATE  is  the  reformat- 
ting of  the  application's  data  base  entities  into  compile- 
able  IDMS  data  definition  language  statements  (see  Exhibit 
6.10).  In  SCHEMA  DESCRIPTION,  a  substitution  of  the  data 
base  name  and  the  current  date  for  SCHEMA  NAME  and  DATE  (see 
lines  7000  and  8000  of  Exhibit  6-10)  is  made.  Although  much 
potential  exists  for  intelligently  tuning  the  data  base 
through  AEEA  and  PILE  DESCRIPTIONS,  this  research  does  not 
address  these  issues.  AREAS  and  FILEs  are  defaulted  to  one 
each  (see  lines  16000  and  2U000  of  Exhibit  6.10).  The  major 
reformatting  work  pertains  to  the  RECORD  and  SET  DESCRIP- 
TIONS. Each  existing  record  and  set  is  obtained  from  the 
desiqned  data  base  and  with  careful  evaluation  of  each  enti- 
ty's parameters,  the  entity  is  converted  to  IDMS  data  defi- 
nition  source   statements. 
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001000* 

00 200  0**** **************************************** ********** 

003000*  **  SCHEMA  DESCRIPTION  **  * 

00  400  0****************************************************** 

005000*  ■ 

OOfcOOO    SCHEMA    DESCRIPTION. 

007000    SCHEMA    NAME    IS    KDB. 

008000    DATE.        12/02/83. 

009000    INSTALLATION.       KSO 

010000* 

0  1  1000****************************************************** 

012000*  **  FILE  DESCRIPTION  **  * 

01 300  0****************************************************** 

014000* 

015000    FILE    DESCRIPTION. 

016000    FILE    NAME    IS    IDMS-FILE1  ASSIGN    TO    SYS010. 

017000    FILE    NAME    IS    JOURNAL  ASSIGN    TO    SYS009. 

018000* 

01900  0****************************************************** 

020000*  **    AREA    DESCRIPTION    **  * 

02  100  0**** ***************************** ********************* 

022000* 

023000    AREA    DESCRIPTION. 

024000    AREA    NAME    IS    DB-AREA 

025000  RANGE    IS     1001     THRD    1100 

026000  WITHIN    FILE    IDMS-FILE1    FROM    1    THRU    100. 

02700  0* 

02  800  0****************************************************** 

029000*  **    RECORD    DESCRIPTION    **  * 

03000  0****************************************************** 

031000* 

032000    RECORD    DESCRIPTION. 

033000    RECORD    NAME    STOCK. 

034000    RECORD    ID     100. 

035000    LOCATION    MODE    CALC    USING    STK-ABRV    DUPLICATES    LAST. 

036000    WITHIN    DB-AREA    AREA. 

037000 

038000 

039000 

040000 

041000 

042000 

043000 

044000 

045000 

046000* 

047000    RECORD    NAME    CLIENT. 

048000    RECORD    ID    200. 

049000    LOCATION    MODE    CALC    USING    CLNT-NAME    DUPLICATES    LAST. 

050000    WITHIN    DB-AREA    AREA. 

051000  05      CLNT-ID  PIC    X  (9)  . 

052000  05       CLNT-NAHE  PIC    X(25). 

053000  05       ANUL-SLHY  PIC    9(6)  . 

05400  0* 

05500  0    RECORD    NAME    STK-CLNT 
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05 

STK-NAME 

PIC 

X  (16). 

05 

STK-ABRV 

PIC 

X(4)  . 

05 

RCNT-QUT 

PIC 

999V9999. 

05 

RCNT-VOL 

PIC 

9(7)  . 

05 

STK-LAST- 

-UPDTE. 

07       STK-DAY-! 

JPDTE 

PIC 

X(6)  . 

07       STK-TIME- 

-OPDTE 

PIC 

X(6)  . 

05 

TOT-AMT-KHEN- 

-REC 

PIC 

999V 9999. 

05 

TOT-NUM-I 

»HEN- 

-REC 

PIC 

9999. 

STK- 

-CLHT- 

-KEY  DN. 

PIC 

X(4)  . 

PIC 

X<9)  . 

PIC 

9(5). 

PIC 

999V99. 

PIC 

X(3)  . 

PIC 

X(3)  . 

TXN- 

-KEY  DN. 

PIC 

X(4)  . 

PIC 

X(9)  . 

PIC 

X(6)  . 

PIC 

X(3). 

PIC 

999V 9999. 

PIC 

9  (4)  . 

056000    RECORD    ID    300. 

057000    LOCATION    MODE    CALC    USING 

058000    WITHIN    DB-AHEA    AREA. 

059000  05      STK-CLNT-KEY. 

OtOOOO  07       STK-ABRV 

061000  07      CLNT-ID 

062000  05      CLNT-STK-QUAN 

063000  05       CLNT-STK-INVST 

064000  05      OWNES 

065000  05      OWNED-BY 

066000* 

067000    RECORD    NAME   STK-CLNT-TXN. 

068000    RECORD    ID    400. 

069000    LOCATION    MODE    CALC    USING 

070000    WITHIN    DB-AREA    AREA. 

071000  05      TXN-KEY. 

072000  07    STK-ABRV 

073000  07    CLNT-ID 

074000  07    TXN-DTE 

075030  05      BRKR-RECHND 

076000  05       CLNT-STK-TXN-PRC 

077000  05       NUM-STK-CLNT-PUR 

078000* 

07900  0****************************************************** 

080000*  **    SET    DESCRIPTION    **  * 

08  100 0* **************************************  *************** 
082000* 

083000    SET   DESCRIPTION. 

084000    SET    NAME    STOCK-CLIENT-0 1       . 

085000    ORDER    IS    SORTED 

086000    MODE  CHAIN    . 

087000    OWNER  STOCK  NEXT    POSITION       1     PRIOR    POSITION    2. 

088000    MEMBER         STK-CLNT       NEXT    POSITION       3    PRIOR    POSITION    4 

089000  LINKED    OWNER 

090000  OWNER    POSITION    5 

09  1000  MANDATORY  AUTOMATIC 

092000  ASCENDING    KEY    IS    STK-CLNT-KEY 

093000  DUPLICATES    NOT    ALLOWED. 

094000* 

095000    SET    NAME    CLIEHT-STOCK-02     . 

096000    ORDER    IS    SORTED 

097000    MODE  CHAIN    . 

098000    OWNER  CLIENT  NEXT    POSITION       1    PRIOR    POSITION    2. 

099000    MEMBER         STK-CLNT       NEXT    POSITION       1     PRIOR    POSITION    2 

100000  LINKED   OWNER 

10  1000  OWNER    POSITION    3 
102000                                                       MANDATORY    AUTOMATIC 

103000  ASCENDING    KEY    IS    STK-CLNT-KEY 

104000  DUPLICATES    NOT    ALLOWED. 

105000* 

106000  SET  NAME  STK-CLNT-TXN-SET. 

107000    ORDER    IS    SORTED 

108000    MODE  CHAIN. 

109000    OWNER       STK-CLNT  NEXT    POSITION    7    PRIOR    POSITION    8. 

110000    MEMBER   STK-CLNT-TXN    NEXT    POSITION    1    PRIOR    POSITION    2 
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1  1  1000  LINKED    OWNER 

112000  08NER    POSITION    3 

113000  MANDATORY    AUTOMATIC 

11*00  0  ASCENDING    KEY    IS    TXN-KEY 

115000  DUPLICATES    NOT    ALLOWED. 

Exhibit    6.10 


6.7  Results  of  Schema  Creation 

Once  the  process  of  handling  each  record  and  set  is  com- 
pleted, a  CMS  file  containing  the  respective  IDMS  statements 
is  created.  The  filename  is  assigned  the  data  base  name  and 
the  filetype  is  SCHMA  (improperly  spelled  as  reguired  the  by 
IDMS/CMS  EXEC  available  at  the  Kansas  State  University  com- 
puting center).  One  can  be  assured  that  the  existing  schema 
will  compile  successfully!  If  the  data  base  designer  pre- 
fers, the  source  file  created  by  DB_GEN  can  be  edited  fur- 
ther before  it  is  compiled. 
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Chapter  7 


SUMARY    AND    CONCLUSIONS 


7 . 1   Contributions   of   this   Re sea rch 

This  research  shows  that  applied  data  base  design  aids 
(e.g.,  data  dictionary  and  normalization)  can  be  integrated 
into  an  encompassing  automated  data  base  design  tool  to  as- 
sist the  data  base  desiqner.  It  is  no  longer  necessary  for 
the  data  base  designer  to  manually  control  large  volumes  of 
data  produced  through  the  data  base  design  process,  manually 
conduct  the  normalization  process  for  hundreds  of  dependen- 
cies, re-execute  schema  compilation  due  to  syntax  errors  or 
conflicting  parameters,  or  develop  his  own  data  base  desiqn 
methodology    through   trial   and   error. 

Although  this  research  relies  heavily  on  research  by  oth- 
ers (YOUR79,ROSS82,CODD70,BERN76) ,  several  areas  lacked  for- 
mal guidance.  One  such  area  was  the  transformation  of  MFDs 
into  sets.  Research  being  done  with  NFDs  pertains  strictly 
to  the  relational  model  (e.g.,  BESN76)  and  no  NFD-to-set 
transformation  processes  were  found  for  the  network  model. 
A  second  area  of  limited  guidance  was  the  transformation  of 
a   conceptual   schema    into  a      physical    CODASYL   network   schema. 
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Several  authors  have  developed  useful  conceptual- to- network 
model  transformations  (ATRE80,CHEN77)  ,  but  none  provide  in- 
siqht  into  the  perplexing  area  of  transforming  multiple  and 
complex  relationships  into  CODASYL  sets  without  user  inter- 
vention. A  final  area  of  importance  is  that  the  entire  de- 
sign process  is  encompassed  in  a  user  friendly  interactive 
menu-driven  system  that  constantly  assists  the  data  base  de- 
signer in  the  development  of  the  user's  data  base  schema. 
Although  another  automated  data  base  desiqn  aid  exists 
(ROSS82),  DB_GEN  is  the  only  known  data  base  design  aid  that 
produces  an   operational  data    base   schema. 

7.2  Status   of   Implementation 

DB_GEN  is  currently  operational  with  the  following  mod- 
ules (refer  to  Exhibit  2.2):  DB_ENTRY,  1EVEL_2,  DB_CUST,  and 
UTILITY_RTNS. 

7.3  E nh ancem en ts    to    DB_GEN 

Retrospection  on  the  system  created,  DB_GEN,  reveals  po- 
tential improvements.  Any  significant  change  to  user  re- 
quirements once  the  data  base  is  customized  leaves  the  user 
with  a  decision  between  reinitializing  all  data  base  enti- 
ties (and  losing  customized  information)  and  adding  the  new 
requirements  without  the  design  power  of  DB_INIT.  Obvious- 
ly, neither  option  is  in  the  user's  best  interest.  A  better 
solution  would  be  to  retain  attributes  of  previous  entities 
and  attempt      to    match   similar   reinitialized      entites.         Data 
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elements  (throuqh   unique  names)  ,  records   (using  candidate 

key  closures) ,   and  sets  (by  their  owner  and  member  records) 

could  be  reestablished  or,   if  not  found,   could  be  added  to 
the  data  base. 

7.  4  Continued  Besear  ch 

Another  potential  improvement  deals  with  the  two  algor- 
ithms in  Chapter  5  that  convert  NFDs  to  CODASYL  sets.  Al- 
though the  algorithms  are  sound,  the  author  feels  that  con- 
tinued research  may  reveal  a  techr.igue  to  further  interpret 
NFDs  that  are  judged  uninterpretable  by  DB_GEH.  Such  an  ex- 
pansion of  either  one  or  both  of  the  algorithms  would  re- 
quire further  study  of  the  intentions  of  the  data  base  de- 
signer at  the  time  an  NFD  was  deemed  necessary  based  on  a 
user  requirement. 

Although  this  research  addresses  important  areas  of  auto- 
mated data  base  modeling  and  implementation,  much  work  re- 
mains. Earlier  stages  of  the  design  life  cycle  could  asso- 
ciate FDs  and  NFDs  with  specific  user  requirements  and 
associate  these  with  organizational  entities.  User  require- 
ments could  be  supplemented  with  response  time  requirements, 
frequency  estimates,  security  measures,  integrity  con- 
straints, and  user  priorities.  Organizational  areas  also 
need  to  collect  information.  By  associating  user  reguire- 
ments  with  an  organizational  area's  priority,  budqet,  vola- 
tility, staff  experience,   hardware  and  software  availabili- 
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ty,  etc.,  potential  data  base  projects  can  be  staged  in  an 
order  most  beneficial  to  the  entire  organization  (COHE79) . 
And  if  DBMS  software  becomes  abundant,  other  software  will 
be  able  to  choose  the  DBNS  that  best  fits  an  organization's 
reguirements.  Once  a  DBMS  is  selected,  initialized,  and 
made  operational,  live  statistics  can  be  kept  to  tune  the 
data  base  management  system  for  efficiency.  For  example, 
groups  of  data  often  accessed  together  can  automatically  be 
stored  contiguously  for  better  performance,  and  if  statis- 
tics indicate  substandard  data  base  response  time  reguire- 
ments, schema  modifications  can  automatically  be  made  to  im- 
prove efficiency  (e.g.,  add  a  secondary  index)  in  order  of 
user  priorities. 
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Appendix  A 


Schema  Data  Definition  Statements 


001000* 

002000************************************************************ 

003000*  **    SCHEMA    DESCRIPTION    **  * 

004000************************************************************ 

005000* 

006000  SCHEMA  DESCRIPTION. 

007000  SCHEMA  NAME  IS  DB-GEN-DB  VERSION  IS  1. 

008000  DATE.   12/02/83. 

009000  INSTALLATION.   KSU 

012000* 

013000    REMARKS.       THIS    DATA    BASE   SCHEMA    IS    USED    TO    SUPPORT    THE 

014000  INPUT-OUTPUT    REQUIREMENTS    EOR    THIS    IMPLEMENTATION. 

018000* 

019000** ************************************* ********************* 

020000*  **    FILE    DESCRIPTION    **  * 

02 1000************************************************************ 

022000* 

023000    FILE    DESCRIPTION. 

024000    FILE    NAME    IS    IDMS-FILE1  ASSIGN    TO    SYS010. 

025500    FILE    NAME    IS    JOURNAL  ASSIGN    TO    SYS009. 

026000* 

0270  00************************************************************ 

028000*  **  AREA  DESCRIPTION  **  * 

029000************************* ******  ***************************** 

030000* 

03  1000    AREA    DESCRIPTION. 

032000    AREA    NAME    IS    DB-AREA 

033000  RANGE    IS    1001    THRU    1100 

034000  WITHIN    FILE    IDKS-FILE1    FROM     1    THRU    100. 

035000* 

036000************************************************************ 

037000*  **  RECORD  DESCRIPTION  **  * 

038000************************************************************ 

039000* 

040000    RECORD    DESCRIPTION. 

041000    RECORD    NAME    DATA-BASE. 

042000     RECORD    ID    100. 

043000    LOCATION    MODE    CALC    USING    DB-NAME    DUPLICATES    NOT    ALLOWED. 

044000    WITHIN    DB-AREA    AREA. 

045000  05       DB-NAME  PIC    X(1c). 

046000  05       DBA  PIC    X  (4)  . 

047000  05       DATE-CREATED. 

048000  07       YEAR-CREATED  PIC    X  (2)  . 

049000  07      MONTH-CREATED  PTC    X  (2)  . 

050000  07       DAY-CREATED  PIC    X(2)  . 

05  1000  05       DATE-CHANGED. 
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052000  07       YEAF-CHANGED  PIC    X  (2)  . 

053000  07      MOUTH-CHANGED  PIC    X  (2)  . 

051*000  07       DAY-CHANGED  PIC    X  (2)  . 

055000* 

056000  RECORD  NAME  RE-CORD. 

057000  RECORD  ID  200. 

058000    LOCATION    MODE    CALC    USING    REC-ID    DUPLICATES    LAST. 

059000    WITHIN    DB-AHEA    AREA. 

060000  05       R3C-ID  PIC    X  (4)  . 

061000  05      REC-NAME  PIC    X(16). 

062000  05      REC-STRG-MODE  PIC    X  (2)  . 

063000  05      REC-LCTN-MODE  PIC   X  (4)  . 

064000  05      REC-D0P-OPTICN  PIC    X  (2)  . 

065000  05      REC-CALC-VIA  PIC    X{16). 

066000  05       REC-AREA  PIC    X(16). 

067000* 

06  8000    RECORD    NAME    DATA-ELEMENT 
069000    RECORD    ID    300. 

070000    LOCATION    MODE    CALC    USING   LMNT-NAM2    DUPLICATES    LAST. 

07  1000    WITHIN    DB-AREA    AREA. 

072000  05       LMNT-NAHE  PIC    X(16). 

073000  05      LMNT-DEF  PIC    X  (55)  . 

074000  05       LMNT-TYPE  PIC    X(17). 

075000  05       TOTAL-SIZE  PIC    9(3). 

076000  05      FRACTION-SIZE  PIC    9{1). 

0770  00* 

078000    RECORD    NAME    SE-T. 

079000    RECORD    ID    400. 

080000    LOCATION    MODE    CALC    USING    SET-NAME    DUPLICATES    LAST. 

08  1000    WITHIN    DB-AREA    AREA. 

082000  05      SET-NAME  PIC    X{16). 

083000  05      SET-LINK  PIC   X  (3)  . 

084000  05       SET-MEM  PIC    X  (2)  . 

085000  05      SET-ORDER  PIC    X  (5)  . 

086000  05       SET-SORT-LMNT  PICX(16). 

087000  05       SET-DUP-OPTION  PIC    X  (2)  . 

088000  05       SET-VALUE  PIC    X  (2)  . 

089000  05      SET-INVRS-VAL  PIC    X  (2)  . 

090000* 

091000    RECORD    NAME   LHNT-BEC. 

092000    RECORD    ID    500. 

093000    LOCATION    MODE    VIA    POPULATED-WITH    SET. 

094000    WITHIN    DB-APEA    AREA. 

095000  05      LMNT-REC-DUMMY  PIC    X  (8)  . 

096000* 

097000    RECORD    NAME    FD-AND-NFD. 

098000    RECORD    ID    600. 

099000    LOCATION    MODE    CALC    USING    LEFT-SIDE    DUPLICATES    NOT    ALLOWED. 

100000    WITHIN    DB-AREA    AREA. 

101000  05      LEFT-SIDE  PlCX(lfc). 

101100  05       HOW-MANY  PIC    X  (2)  . 

10  1200  05       RIGHT-SIDE  PIC    X(16). 

102000* 

103000    RECORD    NAME    CONCAT-LMNT. 
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104000    RECORD    ID    700. 

105000    LOCATION    MODE    CALC    USING    CONCAT-FIELD    DH. 

106000    HITHIN    DB-AHEA    AREA. 

107000  05       CONCAT-FIELD  PIC    X  (  16) . 

108000* 

109000************************************************************* 

110000*  **  SET  DESCRIPTION  **  * 

111000************************************************************* 

112000* 

113000    SET    DESCRIPTION. 

SET    NAME    DEFINED-BY 

ORDEB    IS    SORTED 


114000 
115000 

116000    MODE  CHAIN. 

117000    OWNER  DATA-BASE 

118000  MEMBER  DATA-ELEMENT 
119000 
120000 
121000 
122000 
123000 
124000* 

125000    SET    NAME    DIVIDED-INTO 
ORDER    IS    SORTED 


NEXT    POSITION       3. 
NEXT    POSITION       1 
LINKED    OWNER 
OWNER    POSITION    2 
MANDATORY    AUTOMATIC 
ASCENDING    KEY    IS    LMNT-NAME 
DUPLICATES    NOT    ALLOWED. 


126000 

127000  MODE 

128000  OWNER 

129000  MEMBER 

130000 

131000 

132000 

133000 

134000 

135000* 

136000  SET  NAME 
ORDER  IS 
MODE 
OWNER 
MEMBER 


CHAIN. 


DATA-BASE 
RE-CORD 


LINKED-BY. 
SORTED 


137000 

13  80  00    MODE  CHA     '1. 

139000    OWNER  DATA-BASE 

140000  MEMBER  SE-T 
141000 
142000 
143000 
144000 
145000 
146000* 

147000    SET    NAME    CONCAT-WITH. 
ORDER    IS    SORTED 


148000 

149000    MODE 

150000    OWNER 

151000    MEMBER 

152000 

153000 

154000 

155000* 

156000    SET    NAME 

157000    ORDER    IS 


CHAIN. 
DATA- ELEMENT 
CONCAT-LMNT 


POPULATED- WITH. 
FIRST 


NEXT    POSITION       2. 
NEXT    POSITION       1 
LINKED    OWNER 
OWNER    POSITION    2 
MANDATORY    AUTOMATIC 
ASCENDING    KEY    IS    REC-NAME 
DUPLICATES    NOT    ALLOWED. 


NEXT    POSITION       1. 
NEXT    POSITION       5 
LINKED    OWNER 
OWNER    POSITION    6 
MANDATORY    AUTOMATIC 
ASCENDING    KEY    IS    SET-NAME 
DUPLICATES    NOT    ALLOWED. 


NEXT    POSITION       4. 
NEXT    POSITION       1 
MANDATORY    AUTOMATIC 
ASCENDING    KEY    IS    CONCAT-FIELD 
DUPLICATES    NOT    ALLOWED. 
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158000  MODE 

159000  OWNER 

160000  MEMBER 

161000 

164000* 

165000  SET  NAME 

166000  ORDER  IS 

167000  MODE 

168000    OWNER 

169000    MEMBER 

170000 

171000 

172000 

173000* 

174000    SET    NAME 

175000    ORDER    IS 

176000    MODE 

177000    OHNER 

178000  MEMBER 

1790  00 

180000 

18  1000 

182000* 

183000  SET  NAME 

18  4000  ORDER  IS 

1,85000  MODE 

186000    OWNER 

187000    MEMBER 

18  80  00 
189000 
190000 
191000* 

192000  SET  NAME 
193000  ORDER  IS 
194000    MODE 

19  5000  OWNER 
196000  MEMBER 
197000 
198000 
199000 
200000 
201000 


CHAIN. 


RE-CORD 
LMNT-REC 


GROUPED-IN. 
FIRST 

CHAIN. 
DATA-ELEMENT 
LMNT-REC 


OBNER-OF. 
FIRST 


RE-CORD 
SE-T 


MEMBER-OF. 
FIRST 


RE-CORD 
SE-T 


CHAIN. 


CHAIN. 


INITIALIZED-BY. 
SORTED 

CHAIN. 
DATA-BASE 
FD-AND-NFD 


NEXT    POSITION       5. 
NEXT    POSITION       1 
MANDATORY    AUTOMATIC. 


NEXT    POSITION       3. 
NEXT    POSITION      2 
LINKED    OWNER 
OWNER    POSITION    3 
MANDATORY    AUTOMATIC. 


NEXT    POSITION      3. 
NEXT    POSITION       3 
LINKED    OWNER 
OWNER    POSITION    4 
OPTIONAL    MANUAL 


NEXT    POSITION       4. 
NEXT    POSITION       1 
LINKED    OWNER 
OWNER    POSITION    2 
OPTIONAL    MANUAL 


NEXT    POSITION       4. 
NEXT    POSITION       1 
LINKED    OWNER 
OWNER    POSITION    2 
MANDATORY    AUTOMATIC 
ASCENDING    KEY    IS    LEFT-SIDE 
DUPLICATES    NOT    ALLOWED. 
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2.S5i.£§   Hgdia   Control   Statements 


000100  DEVICE-MEDIA    DESCRIPTION. 

000200  DEVICE-MEDIA    NAME    IS    M DMCL    OF    SCHEMA    NAME    DB-GEN-DB. 

000300  AOTHOB.  MARK    COSTELLO. 

000400  DATE.  09/13/83. 

000500  INSTALLATION.  KSU. 

000600  REMARKS.  DMCL    FOR    DB_GEN. 

000700 

000800  BUFFER    SECTION. 

000900  BUFFER    NAME    IS    IDMS-BUFFER 

00  1000  PAGE    CONTAINS    49fc    CHARACTERS 

00  1100  BUFFER    CONTAINS    100    PAGES. 

001200 

00  1300  AREA    SECTION. 

00  1400  COPY    DB-AREA    AREA. 
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Subschema   Data   Deflation   Statements 
000100    ADD   SUBSCHEMA    NAME    IS    MSIJB 


000200 

OF    SCHEMA    NAME    IS    DB-GI 

000300 

DHCL 

NAME    IS    MDMCL. 

0004  00 

ADD 

ABEA 

DB-AREA. 

000500 

ADD 

RECORD 

DATA-BASE. 

oooeoo 

ADD 

RECORD 

RE-CORD. 

000700 

ADD 

RECORD 

SE-T. 

000800 

ADD 

RECORD 

DATA-ELEMENT. 

000900 

ADD 

RECORD 

LMNT-REC. 

000950 

ADD 

RECORD 

CANDIDATE-KEY. 

000975 

ADD 

EECORD 

CONCAT-LMNT. 

00  1000 

ADD 

SET 

DEFINED-BY. 

001050 

ADD 

SET 

DIVIDED-INTO. 

001100 

ADD 

SET 

LINKED-BY. 

001200 

ADD 

SET 

HEMBER-OF. 

001300 

ADD 

SET 

OHNER-OF. 

001325 

ADD 

SET 

POPULATED-WITH. 

001350 

ADD 

SET 

GROOPED-IN. 

001375 

ADD 

SET 

DETERMINED- BY. 

001400 

ADD 

SET 

CONCAT-WITH. 

00  1500    GENERATE. 
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Data   ganiEUltion   Source    Statements 

/*DHLIST*/ 

/*SCHEilA_COEMENTS*/ 

DB_GEN:       PBOC    OPTIONS     (MAIN)  ; 

/***********************************************$****************/ 
/*****************************  t^ttttttttt************************^ 

/*  This   program   automates   the   data   base   design    process   through   */ 

/*  the   use   of   applied    data   base   design   principles.      The    output    */ 

/*  of   this   implementation   is   operational   IDHS   schema   data               */ 

/*  definition   statements   representing   a    user's   data   base                 */ 

/*  schema.                                                                                                                              */ 

/*  */ 

/*  written   by:    Bark   costello                                                                              */ 

/*  */ 

/*  date:      December    1983                                                                                               */ 

/*  */ 

/*  The  block   diagram   on  the   next   page   illustrates   the   major           */ 

/*  modules   for   this   program.      Each    module   will   be   broken  down      */ 

/*  further  into    sub-modules.                                                                                   */ 

/*********************  ***#*********#******#***#*#»4  *********  *****/ 

/♦a******************************************************* »»**** */ 
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/* 
/* 

/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 


DB_GEN 

+ + 

J  I 

i     DB    ENTRY    J 
I  I 


I 

|     LEVEL_2 

! 

+ 

+ 


|       PEINT_       | 
I        DATA  | 

1  1 

•». + 

+ + 

1  i 

I    UTILITY_    | 
I       RTNS       "    I 


DB    INIT 


I  I 

|  DEPENDENCY     1 

I  ENTEY             | 

I  I 


+ 

CKEATE    LMNT    HEC 


+ i 


BEEN    ALG 


I     I 

I     I 

+    | 

+ + 


+ 

CEEATE_SET 

1  CREATE_  | 
I  MEMBEE_  1 
I     HECOBD  | 


+ 


♦ +  , 

|    CREATE_       1  | 

I     OWNER_~       1  J 

|     EECOED  |  | 

* *  J 

+ 


+ 


I  DB_CUST 

1  I 

1  1 

DB 

1 

1 

1 
1 

LMNT 

1  i 
1  1 

UPDATE 

1 
1 

1 
1 

UPDATE 

I  1 
1  1 
1  1 
1  1 
1  *~ 

EECOED 

update" 

i 
.1 

1 

1 

-*• 

1 
1 
1 

1 
+  - 

SET 

UPDATE 

SCHEMA  CREATE 


+ «. 

I  I 

|  SIMPLE  I 
J   M_N    | 

I  "        I 
•f + 


+ + 

I  I 

I  POINTER | 
I  _CEEATE| 

I  I 

+ + 


I  I 

I  MISSING  I 
I  _DATA_  | 
I  CHECK  | 
+ * 

+ + 

I  I 

I     DDL_  | 

I     CREATE    | 

I  I 

+ + 


+ 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
V 

*/ 
*/ 
*/ 

*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


/    **  *********************************  ****#***##*#*#!(,******#*#  ^jj.^^,,^ 
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/*   This   is   the   main   driver   module.      To   precede   from   this    module    */ 
/*   one   must   either  create   a    new   data   base,    or   select  */ 

/*   an    existing   data-base  for   enhancement   or   study.  */ 

/***************♦ ***********************************#***********#/ 

DCL     (IDMS, ABORT)    OPTIONS     (INTER,  ASK)     ENTRY; 

DCL      CLRSCR    ENTRY; 

DCL     (MSUB    SUBSCHEMA,    DB-SEN-DB    SCHEMA    VERSION     1) 
MODE     (BATCH); 

INCLUDE    IDMS     (SUBSCHEM  A_DESC  RIPTION)  ; 

INCLUDE    IDMS     (SUBSCHEMA_BINDS) ; 

READY    AREA    (DB    AREA)     PROTECTED    UPDATE; 

CALL   IDMS_STATUS; 

/*      IF    I    GET    A    MESSAGE    0966    FROM    HERE    THEN    I    MOST    UNLOCK 
BY    "AREA(S)".       THIS    HAPPENS    IF    THE    PROGRAM    ABENDS. 
EITHER    RE    "IDMSINIT    DBASE"     (WHICH    LOSES    WHAT    IS    IN 
THE    DATA    BASE)     OR    USE    THE    "PFIX    UTILITY"     (SAVES 
WHAT    IS    IN    THE    DATA    BASE) .       SEE    NOTES.  */ 

INCLUDE    IDMS     (I DMS_STATUS) ; 

DCL  (OK,REC_FOUND)  CHAR  (4)     INIT     ('0000'), 

EDIT_OUT  CHAR (72) , 

MENU_ENTKY  CHAR  (6  9)  , 

MSG  CHAR  (60)  , 

ENTER_KEY  CHAR  (1)  , 

(I, J, COUNT)  FIXED    DEC(3)  , 

DISPLAYJTBL  (500)  CHAR  (72), 

DOP!AIN_TBL(500)  CHAR  (16), 

(SAVE_DB_NAME,SAVE_NAME)  CHAR  (16)  , 

DB_KEY_TBL(500)  FIXED    BINARY(31), 

HEND_NUH  CHAP  (3)  ; 

HENU_ENTRY    =    *     •; 

CALL    DB_ENTRY     (  MEHtJ_NUM,  MENU_ENTR  Y)  ; 
DO    WHILE       (MEN0_NUM         -.=        'X')! 
IF      MENU_NUM       =       '1' 
THEN 

CALL       NEW_DB     (MENU_NUM , MENU_ENTRY) ; 
ELSE    DO; 

OBTAIN    CALC    RECORD     (DATA    BASE)  ; 
CALL    IDMS_STATUS; 
CALL    LEVEL_2     (MENU    ENTRY)  ; 
END; 

CALL    DB    ENTRY     (MENU_N  UM,MEN  II_ENTR  Y)  ; 
END; 

FINISH; 
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DB_ENTHY:       PROC    (MENU_NUM,    MEND    ENTRY); 

/*  This  routine  displays  the  primary  menu  and  accepts  the  reply.*/ 
/*  The  primary  menu  consists  of  an  option  to  start  a  new  data  */ 
/*  base,  select  a  data-base  that  already  exists,  or  exit  from  V 
/*  the  system.  The  MENU_NUM  parameter  returns  an  "X",  "1"  or  a  */ 
/*   valid   menu   number.         {Note:      "x"    stands   for   exit)  */ 

/*  If    BENU_NUM    is   a   valid   menu   number   then   the   respective  */ 

/*   data   base   will  be    made    "current".  */ 

/Mr***************************  *^*t*********#**********t*****«*^ti*/ 

/*  */ 

/*  + +  ♦ +  + +  */ 

/*  I  II  II  IV 

/*     |   DB_ENTRY   ]         |   NEW_DB   I       |  DB_UP_MENU  )       */ 

/*           1                             II                         II  IV 

/*         + +  + +  + +  */ 

/*  */ 

DCL  SLCT_NUM  FIXED    DEC(3)  , 

MENH_NUM  CHAE(3)  , 

MENU_ENTRY  CHAR (fc9) ; 

/*  LOAD       NAME    TABLE   WITH    DATA    BASES  */ 

DISPLAY_TBL    =    ■     •; 

POT    STRING     (DISPLAY_TBL{1)  )     EDIT     ('!)       CREATE    DATA    BASE') 

(X(K)  ,A)  ; 

OBTAIN  FIRST  RECORD  (DATA_BASE)  AREA  (DB.AREA)  ; 

IF  ERROR_STATHS  -.=  '0307'~ 

THEN  CALL  IDMS_STATOS; 

COONT  =  1 ; 

DO    WHILE     (ERROR_STATUS    =    REC_fOUND) ; 

COUNT   =    COUNT    +    1; 

PUT    STRING     (DISPLAY_TBL (COUNT) )     EDIT     (COUNT,')        ', 
DB_NAME)      (X(2)  ,F(3),2  (A)  )  ; 

OBTAIN    NEXT    RECORD     (DATA_BASE)     AREA     (DB_AREA)  ; 

IF    EHROR_STATUS    -.=     '0307' 

THEN    CALL    IDMS_STATUS; 
END; 
PUT    STRING     (DISPLAY_TBL  (COUNT    +     1)) 

EDIT    ('  X)       EXIT')     (A)  ; 

/*  DISPLAY    MENU      /       ACCEPT    EDITED    REPLY         */ 

DB_NAME   =    '     '  ; 

CALL    GEN_MENU     (MENU_NUM, MENU_ENTRY, 

'**    DATA    BASE    ENTRY    **'7    COUNT, SLCT_NUK,  3)  ; 

/*         SET    CURRENCY    FOR    RESPECTIVE    DATA    BASE      */ 

IF    ->(MENU_NUM    =     'X'       1       MENU_NUM    =    '1') 
THEN    DO; 
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DB_NAME 
END; 
END    DB    ENTRY; 


SHBSTR  (DISPLAYJTBL  (SLCT_NUM)  ,9,  16)  ; 


NEH_DB:  PEOC     (MENU_NUH,  MEN  U_ENTR  Y)  ; 

/*  This    module   establishes   a   new    user's   data   base   for    develop-  */ 

/*  merit.      Fields   of   the   DATA   BASE   structure  are  assigned    values  */ 

/*   and   then    the    DATA   BASE   occurrence   is   stored  in   DB_GEN's   data  */ 

/*   base.  */ 


DCL 


SLCT 

MENU_NUM 

STATUS 

HENU_ENTRY 

D 

DATE 


CHAR  (72)  , 
CHAR(3)  , 
CHAR  (4)  , 
CHAR  (69)  , 
CHAR  (6)  , 
BUILTIN; 


DATA_B 
IF    MEN 
THEN 
CALL 

ELSE 

MENU 
DO    Will 

IF    B 


ASE    =    • 
U   ENTRY 


ELSE 
CALL 
END; 


DB_UP_MENU     (MENU_NUM,  ME  MJ_  ENTRY, 

• **  CREATE  NEW  DATA  BASE  **•) 

_NUM   =    •  1«; 

LE    (MENU_NUM    -.=     'X')  ; 

ENU_NUM    =    ■ 1*       THEN    DO; 

DB_NAME    =    MENU_ENTRY; 

CALL    EDIT_NAME     (DB    NAM  E,ST  ATUS)  ; 

IF    STATUS    =    'GOOD' 

THEN    DO; 

FIND   CALC    RECORD     (DATA_BASE)  ; 
IF    ERROR_STATUS    -.=    '0326' 
THEN    CALL    IDMS_STATUS; 
IF    ERROR_STATIJS    =    REC_FOIJND 
THEN    DO; 

PUT  STRING  (MSG)  EDIT 

(DB_NAME,'    ALREADY    EXISTS")      (2(A)); 
CALL    MESSAGES; 
DB_NAME    =    '     '; 
END; 
END; 
ELSE 

DB   NAME   =    ■     •; 
END; 
IF    MENU_NUM    =    > 2'       THEN 

DBA    =    MENU_ENTRY; 
DB_UP_HENU     (ME'ND_NUM,  MENU_ENTRY, 

•  **  CREATE  NEW  DATA  BASS  **•) 


IF   DB_NAME 
THEN  DO; 


-  1  15 


MSG    =     'DATA    BASE    NAHE   IS    BLANK    —    NO    ADD    MADE'; 

CALL    MESSAGES; 

RETURN; 

END; 

D  =    DATE; 

YEAR_CHEATED,    YEAE_CHANGED   =    SIJBSTR  (D,  1  ,  2)  ; 
MONTH_CREATED,     MONTH_CHANGED    ■    SUBSTR  (D,  3,  2)  ; 
DAY_CREATED,    DAY_CHANGED    =    SUBSTR  (D,  5,  2)  ; 
STORE    RECORD    (DATA_BASE)  ; 
CALL   IDMS_STATnS; 
END    NEW_DB; 

DB_UP_MENU:       PROC    (MEHU_NUM,  MENO_ENT  RY  ,  MENU_MSG)  ; 

/********** **********************#*******************************/ 
/*   This   module   displays  the    fields   to   be   added   or    modified  */ 

/*    for    the    DATA    BASE   structure.  */ 

/******************  **********************************************, 

DCL  SLCT_NUM  FIXED    DEC  (3), 

SLCT  CHAR  (72), 

STATUS  CHAR(4) , 

WENU_NUM  CHAR(3), 

MENU_ENTRY  CHAR  (69), 

MEHU_MSG  CHAR  (30); 

STATUS   =    'BAD' ; 
DO    WHILE     (STATUS    =    'BAD')  ; 
CALL    CLRSCR; 

PUT    STRING     (EDIT_OUT)     EDIT     (MENU_MSG) 

(X(15)  ,A)  ; 
DISPLAY     (EDIT_OUT)  ; 
CALL    BLANK_LINE(2)  ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(M)        DATA    BASE    NAKE:        ',DB_NAME)      (2(A)); 
DISPLAY     (EDIT_0UT)  ; 
PUT    STRING     (EDIT_OUT)     EDIT 

('2)        DATABASE    ADMINISTRATOR:        ',DBA)      (2(A)); 
DISPLAY     (EDIT_OUT)   ; 

PUT    STRING     (EDIT_OUT)     EDIT     ('X)        EXIT')      (A)  ; 
DISPLAY     (EDIT_0DT) ; 
CALL    BLANK_LINE(2)  ; 
DISPLAY     (»S=  =  ><)  EEPLY     (SLCT); 

CALL    EXAMINE_ENTRY     (SLCT, MENU_NUM,  MENU    ENTRY, SLCT_ NUM, 
STATUS, 2)  ; 
END; 
EHD    DB_UP    MEND; 
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LEVEL_2:       PROC    <M  EN  U_ENTRY)  ; 

/****************************************************************/ 
/*   This   module   calls   the   modules    representing   the   primary  */ 

/*   services    of    DB_GEN.  */ 

/******#*************#*****#***#***«  *&  *************  t  *%**  *t  z+m:**/ 

/*  */ 

/*  LEVEL_2  */ 

/*  */ 

/*  + 1  t/ 

/*  I  I  V 

/*  I    PRIMARYJIENU     |  */ 

/*  I  I  V 

/*  + +  v 

/*  */ 

/***************************************************** ***********y 

DCL       HENU_NUM  CHAE  (3)  , 

MENO_ENTRY  CHAB(69)  , 

DEL_SH  CHAR  (1)  , 

SLCT_2  CHAR (72) ; 

IF    MENU_ENTRY    =    '  DELETE' 
THEN    DO; 

POT    STRING     (HSG)     EDIT 

(DB_NAME,'    DATA    BASE    DELETED  • )  (2  ( A)  )  ; 

ERASE    RECORD     (DATA_BASE)     ALL; 

CALL    IDMS_STATUS; 

CALL    MESSAGES; 

RETURN; 

END; 

CALL    PRIMARY_f1EN0; 
DO    HHILE       (SLCT_2       -.=       'X'); 
IF      «ENO_NUB      =       '1'    THEN 

CALL-    LMNT_UPDATE     (MENU_ENTEY)  ; 
ELSE    IF      MENO_NUM      =       '2'       THEN 

CALL       RECOED_nPDATE    (MENU_ENTSY) ; 
ELSE    IF       MENO_NUM      =       '3'       THEN 

CALL       SET_IJPDATE     (MEN  U_ENTP.Y)  ; 
ELSE    IF      MENU_NU«       =       '4'       THEN 
DO; 

CALL    CHG_DEL_DB     (DEL_SW)  ; 

IF    DEL_SW   =     'D' 

THEN 

RETURN; 
END; 
ELSE    IF       MENU_NUM       =       '5'       THEN 

CALL       PRINT_DATA; 
ELSE    IF      MENU_NUM    .=       '6'       THEN 

CALL       CREATE_SCHEMA; 
ELSE    DO; 

HSG    =     'ERROR:       LEVEL_2    CASS    STATEMENT'; 
CALL    MESSAGES; 
END; 
CALL    PRIMARY_MENO"; 
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END; 

PRIMARY_MENU:       PEOC; 

/*********************************** 4*************************44^ 

/*  This    module   displays   the    primary    menu   of   services   of   DB   GEN.    */ 

/************  *********************************************** 44** *^ 

DCL  SLCT_STATUS  CHAD  (4), 

SLCT_NUM  FIXED    DEC{3)  ; 

SLCT_STATUS    ■     'BAD1; 

DO    HHILE     (SLCT_STATUS    =    'BAD'); 

HSG   =    ■ **    PRIMARY       MEND    **■; 

CALL       MENU_HEAD; 

DISPLAY        ('!)        DATA    BASE    INITIALIZATION'); 

DISPLAY        ('2)        DATA    ELEMENT    UPDATE  •)  ; 

DISPLAY       ('3)        RECORD    UPDATE  '); 

DISPLAY       {'«)       SET    UPDATE  '); 

DISPLAY        ('5|        DATA    BASE    UPDATE  '); 

DISPLAY       ('6)        PRINT    DATA  •); 

DISPLAY   ['V)   CREATE  SCHEMA  ')  ; 

DISPLAY   ("X)    EXIT  <)  ; 

CALL    BLANK_LINE(2)  ; 

DISPLAY       (T==>')       REPLY        (SLCT_2)  ; 

CALL    EXAMINE_EUTRY     (SLCT_2 ,MENU_NUM, MENU    ENTRY, 
SLCT_B[JS,SLCT    STATUs77); 
END; 
END    PRIMAHY_PIENU; 
END    LEVEL_2; 
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DB. 

INIT:       PEOC; 

/******************************************************* 

/* 

Th 

is   is   a   major  global   module    of    DB. 

_GEN. 

Once   comple 

/* 

wi 

11   accept    functional  and   nonfunct 

ional   dependencies 

/* 

use   those   dependencies   to  create   instances   of   the 

/* 

DATA-ELEMENT,     RECORD,    and    SET    structures. 

The   establ 

/* 

of 

these   structure 

instances   is   described 

in   the   thes 

/* 

su 

sporting   this  implementation. 

/******************************************************** 

/* 

/* 

DB 

_IHIT 

/* 

INIT_DB_ENTITIE£ 

1         1 

DB_ISIT_ 

/* 
/* 
/* 
/* 
/* 

|    CEEATE_         |     | 
|     LMNT    EEC       |     | 
1     ♦ ♦    1     1 

1     1     BEEN_    |     |     | 

CREATE_                     J 
SET                                | 

|    INTERPEET_    |     | 

1         1 

MENU 

1         I 

ENTER         | 

/* 
/* 
/* 

1     1    ALG          III 
1     + ♦     1     1 

I    RS_NFD               |     1 

1         1 

FDS               | 

/* 

1 

|    INTERPEET_    |     | 

1         *• 

+ 

/* 
/* 
/* 

1 

i 

I    LS_NFD               I     I 

1         1 

EKTER_    | 

NFDS          | 

+ 

1 
+  - 

+. 

1         1 
1         +" 

/♦         + 1 

y* *********************************************  ********** 

MSG    ■    'CEEATE_SCHSMA    TO    BE    COMPLETED'; 

CALL    MENU_HEAD; 

DISPLAY     {'PRESS    ENTER    TO    CONTINUE')     REPLY     (ENTER_KEY); 

END      CREATE    SCHEMA; 
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/**********  *»<.♦*****»#*****«**  ************************  ***********/ 
/*  **      The   DB_CUST    modules   starts   here.    **  •      */ 

/*  V 

/*  The   module   name   DB_CUST   only   serves   as   a   loqical   groupinq  */ 

/*   of   modules   and  is   not   itself   an   actual   module.      The   modules      */ 
/*    within   DB_CUST   follow.  */ 

/****************************************************************/ 


NEW_LMNT 

I     NEW_  | 

i     LHNT_NAHE    1 


I    LMNT_ 

]     NEW_MEND" 


LMNT_UPDATE:       PROC  (MENU_ENTRY)  ; 

/*********************************** 

/*  This  module  displays  all  existinq 
/*  for  the  "current"  DATA_BASE  struc 
/*  to  add  a  new  DATA_ELEMENT  occurre 
/*  DATA_ELEMENT  occurrence,  or  delet 
/*  occurrence. 

/************* * ************** 
/* 

/*         LHNT_OPDATE 

/* 

/*    + 

/*     I 

/*    I 

/*     I 

/*    1 

/*    I 

/* 

/* 

/* 

/* 

/* 

/* 

/*  |    TOTAL_    |        |    FRCTN_ 

/*  I     SIZE_       !        1     SIZE_ 

/*  I     RTN  1        |     BTN 

/*  + +  + 

/*  J     LflNT_  1  |     LMNT_ 

/*  |     TTPE_HTN     |  |     DEF_RTN 

/*  + +  +  — 

/* 

/**************************** 


**************** 
DATA_ELEMENT    oc 
ture   and  allows 
nee,    change   and 
e   an    existinq    DA 


************************ 


•+   ♦ 

|     |     MEW 

I     I     _FI 
•+    1     +  — 

I  I  D 
I  J  C 
J     ♦— 

+ 


_CONCAT 
ELD 


UP. 
K 


j.    + 


I 
I 

— + 


+ 

CHG_C0NCAT_FI3LD 
+ + 


I       DUP_ 
|       CK 
+ 


+ 


************************ 


*************/ 
currences  */ 
the   user  */ 

existinq  */ 

TA_ELEMENT       */ 

*/ 

************* ^ 

*/ 

*/ 

*/ 
+    */ 

*/ 

*/ 
*/ 
*/ 
*/ 

V 
*/ 
*/ 
*/ 
*/ 
V 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
«.    */ 

*/ 
*************/ 


CHG_DEL_LMNT 

+ + 

I  LMNT  ! 
|  CHG_~  | 
|  MENU  | 
+ + 


CHG_  | 
LMNT_  | 
HAME~    I 


i 


DCL 


MENU_EHTRY 
SLCT_NnM 
MENU    NUM 


CHAR(69)  , 
FIXED  DEC  (3) 
CHAR(3)  ; 


/*  IF  DATA  ELEMENT  NAME  SUPPLIED  THEN  SKIP  DATA  ELEMENT  MENU  */ 

. 

IF    MENO"_ENTRY    -.=    •     ' 
THEN   DO; 

LMNT_NAME    =    MENrj_ENTEY; 

SAVE_DB_NAME  =  DB_NAME; 

OBTAIN    CALC    RECOED     {DATA_ELEMENT)  : 
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DO    WHILE     (EBROH_STATUS    =    REC_FOUND)  ; 

OBTAIN    OWNER    SET     (DEFINED_BY) ;       CALL    IDMS    STATUS; 

IF    SAVE_DB_NAME    =    DB_NAME 

THEN 

ERROR_STATUS    =     'FWND'; 

ELSE 

OBTAIN    DUPLICATE    RECORD     {DATA    ELEMENT); 
END; 

IF     (ERROR_STATUS    -=     '0326'     E    ERROR_STATUS    -■=    'FWND1) 
THEN    CALL    IDMS_STATUS; 
IF     (ERROR_STATUS    =     ' FHND») 
THEN    DO; 

MENU_ENTRY    =    ■     ' ; 

CALL  CHG_DEL_LKNT  (MENU_2NTRY)  ; 

RETDRN; 

END; 
ELSE  DO; 

DB_NAME  =  SAVE_DB_NAME; 

OBTAIN    CALC    RECORD     (DATA_BASE)  ; 

POT   STRING     (MSG)     EDIT     (MENU    ENTRY, 

'     IS    NOT    AN     EXISTING    DATA    ELEMENT')      [A  (16),  A)  J 

CALL    MESSAGES; 

END; 
END; 

/*  LOAD    TABLE    WITH    DATA    ELEMENT    NAMES  */ 

MENU_NDM    =     '     ' ; 
DO    WHILE     (HENU_NUM    -=     'X')  ; 
DISPLAY_TBL    =     •     ■  ; 

PUT    STRING     (DISPLAY_TBL(1)  )     EDIT     (M)        CREATE    ELEMENT') 

(X(4),A)  ; 
OBTAIN    FIRST    SET    (DEFINED_BY) ; 
IF    ERROR_STATUS    -=     '0307' 
THEN    CALL    IDMS_STATUS; 
COUNT   =    1 ; 
DO    WHILE     (ERROR_STATUS    =    REC_FOUND); 

COUNT    =    COUNT    +     1; 

PUT    STRING     (DISPLAY_TBL (COUNT) )     EDIT     (COUNT,*)        ', 
L8NT_NAME)        (X  (2)  , F  (3)  ,2  (A)  )  ; 

DB_KEY_TBL  (COUNT)     =    DBKEY; 

OBTAIN    NEXT    SET     (DEFINED_BY)  ; 

IF    ERROR_STATUS    -■=     '0307' 

THEN    CALL    IDMS_STATUS; 
END; 

PUT    STRING    (DISPLAY_TBL(COUNT    +     1)) 
EDIT     (•  X)        EXIT')      (A)  ; 

/*  DISPLAY    MENU         /       ACCEPT    EDIT    REPLY         */ 

CALL    GEN_MENU  (MEND_NUM,HENII_EMTRY, 
'**    DATA    ELEMENT    UPDATE    **', 
COUNT,SLCT_NUM,3) ; 
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IF    MENU_NUM    =    '  X' 
THEM 

RETURN; 

/*      CONTINUE    TO    UPDATE    DATA    ELEMENTS    UNTIL    EXIT         */ 

IP   SLCT_NUM    =    1 
THEN 

CALL    NEW_LMNT     (M  ENU_ENTR  Y)  ; 
ELSE    DO; 

LMNT_NAME    =    SUBSTR  (DISPL AY_TBL  (SLCT_NUM)  ,9  ,  1  6)  ; 
OBTAIN    RECORD     (DATA_ELEBENT) 

DBKEY     (DB_KEY_TBL(SLCT_NUM)  )  ; 
CALL    IDHS_STATUS; 

CALL    CHG_DEL_LHNT     (MENU    ENTRY)  ; 
END; 
END; 
NEW_LMNT:  PROC     (MENO_ENTRY)  ; 

/*   This    nodule    establishes    a    new    DATA_ELEMENT   occurrence    by  */ 

/*   defaulting   the   DATA_ELEMENT   fields   and  calling   the   modules  */ 

/*   to    update  these   fields    based   on   the    user's   MENU_ENTRY.  */ 

/*   Once   updating   is   complete,    the   new   DATA_ELEMFNT   occurrence  */ 

/*   is   stored.  */ 

DCL  HENU_NUH  CHAR  (3)  , 

MENU_ENTRY  CHAR  (69)  , 

SLCT_NUM  FIXED  (3)  , 

NUM_CONCAT  FIXED  (3), 

CONCAT_TBI.  (20)  CHAR  (  16)  , 

'       (LOW_LIMIT,UP_LIMIT)  FIXED(3)  ; 

/*********   INITIALIZE    AND    DEFAULT    RECORD    FIELDS      *************/ 
SLCT    NUM    =    0; 


NUM_CONCAT 

=    0 

CONCAT    TBL 

=     • 

t  • 

UP    LIMIT 

= 

5; 

LOW_LIMIT 

= 

5; 

LMNT_NAME 

= 

■    i  > 

LMNT    DEF 

= 

i    i  - 

LMNT_TYPE 

= 

•CHARACTER'  ; 

TOTAL_SIZE 

= 

10; 

FRACTION_SIZE 

= 

0; 

/*  AS    AN    ELEMENT    NAME    BEEN    PROVIDED    FROM    SECONDARY    MENU      */ 

IF    MENU_ENTRY    =    '     • 
THEN 

CALL    LMNT_NEW_MENU     (MENU_NUM  ,  MENU_ENTRY,SLCT_NUM)  ; 
ELSE 

MENU   NUM    =    • 1'  ; 
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/*         ADD    ELEMENT    ATTRIBUTES    UNTIL    EXIT  */ 

DO    WHILE    (MENU_NUM    -.=    'X'); 
IF    MENU_NUM    =    ' 1'     THEN 

CALL    NEW_LMNT_NAME     (  HENU_ENTE  Y,  LMNT_NAME)  ; 
ELSE    IF    HENU_NOM    =    '2'     THEN 

CALL    LMNT_DEF_RTN     (MENU_2NTRY  ,LMNT_DEF) ; 
ELSE   IF    MENU_NUM    =    '3'     THEN 

CALL    LMNT_TYPE_RTN     (MENIJ_ENTR  Y,  LMNT    TYPE); 

/* 1 */ 

IF     (LMNT_TYPE    =    "CHARACTER'     &    MENU_NUM    =     'I')     THEN 
CALL    TOTAL_SIZE_RTN     (MENU_ENTRY,  TOTAL_SIZE)  ; 
ELSE    IF     (LMNT_TYPE    =    ^NUMERIC     6    MEND_NUM    =    '4')     THEN 

CALL    TOTAL_SIZE_RTN     (MENU_ENTRY,TOT  AL_SIZE)  ; 
ELSE    IF    (LMNT_TYPE    =    'NUMERIC     S    MENU_NUM    =     '5')     THEN 
CALL    FRCTN_SIZE_RTN     ( MENU_ENT RY, FRACTI0N_S1ZE) ; 
ELSE    IF     (LHNT_TYPE   =     'CONCATENATED'     S 

(MENU_NUM    >=    ' U'     5    SLCT_NUM    <    LOW_LIMIT)  )     THEN 
CALL    NEW_CONCAT_FIELD     (SLCT_NUM, MENU_ENTRY) ; 
CALL    LMNT_NEW_MENU     (MENU_NUM  ,  MENU_ENTRY,SLCT_NUM)  ; 
END; 

IF    LMNT_NAME    =    '     • 
THEN    DO? 

MSG    =     'ELEMENT    NAME    IS    BLANK    —    NO    ADD    MADE'; 

CALL    MESSAGES; 

RETURN; 

END; 
STORE    RECORD     (DATA_ELEMENT)  ;       CALL    IDMS_STATUS; 

/******      STORE    AND    CONNECT    DATA    ELEMENT    WITH    ITS    *********/ 
/«»****       CONCATENATED    FIELDS  *********/ 

DO    I    =    1    TO    NUM_CONCAT; 

CONCAT_FIELD   =    CONCAT_TBL  (I)  ; 

STORE    RECORD    (CONC AT_LMNT)  ; 
END; 

LMNT_NEW_MENU:       PROC     (MENU_NUM  ,MENU_ENTR  Y,SLCT_NIJM)  ; 
/***********************************************#*♦******#****»**/ 

/*  This   module  displays  the    various   DATA_ELEMENT   fields   that  */ 

/*   can    be   updated   for    a   selected    DATA_ELEMENT    occurrence.  */ 

/ ******************************* + ******************************** ^ 

DCL  MENU_NUM  CHAR{3)  , 

MENIJ_ENTRY  CHAR  (69)  , 

(I,SLCT_NUM)  FIXED  (3); 

/***       LOAD    DISPLAY    TABLE    ***/ 

DISPLAY_TBL    =     '     • ; 

PUT    STRING     (DISPLAY_TBL{1))     EDIT 

('        1)     ELEMENT    NAME:     ',LMNT_NAME)      (2(A)); 
PUT    STRING     (DISPLAY_TBL(2)  )     EDIT 
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("   2)  DEFINITION:  >,LMNT_DEF)   (2(A)); 

PUT  STRING  (DISPLAY_TBL(3))  EDIT 

(■   3)  TYPE:  ',LHNT_7YPE)   (2(A)); 
/* v 

IF     (L«NT_TYPE    =    '  CHARACTER'     i     LMNT_TYPE   =     •     ■)     THEN 
DO; 
PUT    STRING     (DISPLAY_TBL  (4))     EDIT 

(•       4)     TOTAL    SIZE:     ',TOTAL_SIZE)      (2(A)); 
OP_LIMIT   =    4; 
END; 
ELSE    IF    LMNT_TYPE   =     'NUMERIC'     THEN 
DO; 
POT    STRING     (DISPLAY_TBL{4))     EDIT 

('       4)     TOTAL    SIZE:     •  ,TOTAL_SIZF)      (2(A)); 
POT    STRING     (DISPLAY_TBL(5))     EDIT 

(•       5)     FRACTION    SIZE:    ■  ,  FRACTION_SIZE)      (2(A)); 
OP_LIHIT   =    5; 
END; 
ELSE    IF    LMNT_TYPE    =     'CONCATENATED'    THEN 
DO; 

DISPLAY_TBL(4)     =     '       4)     ADD   SOB    ELEMENT'; 
DISPLAY_TBL  (5)     =    •       DELETE    SOB    ELEMENT    .     .     .'; 
OP_LIMIT   =    4; 
1    =   0; 

DO    HHILE     (CONCAT    TBL(I+1)     -•=    '     '); 
1=1+1; 

OP_LIMIT   =    0P_LIMIT    +    1; 
PUT    STRING     (DISPLAY_TBL(I  +  5))     EDIT 

('        ',UP_IJ.MIT,')      ',CONCAT_TBL(I)  )      (A,  F  (3)  ,  2  (A)  )  ; 
END; 

NOM_CONCAT  =  I; 
END? 
DISPLAY_TBL  (UP_LIMIT  +  1)  =  '   X)  EXIT'; 

CALL  GEN_MENU  (MENJJ_NUM,  M  ENU_ENTR  Y,  '  **  CREATE  NEW  ELEMENT  **'  , 
OP_LIMIT,SLCT~NUM,  1)  ; 
END  LMNT_NEW_MENU; 

NEH_LMNT_NAME:     PROC  (MENU_ENTR Y,LMNT_NAME)  ; 

/*  This  module  allows  the  user  to  assign  a  data  element  name  */ 
/*  to  a  newly  created  DATA_ELEMENT  occurrence.  Before  the  name  */ 
'/*  is  accepted,  a  check  is  made  to  verify  that  it  does  not  */ 
/*  already  exist.  */ 

DCL  MENU_ENTRY  CHAR(69), 

(LMNT_NAME,SAVE_NAME)     CHAR  (16), 
STATUS  CHAR  (4)  ; 

LMNT_NAME  =  MEHO_ENTRY; 

CALL    EDIT_NAME    (LMNT_N  AME,  STATUS)  ; 

IF  STATUS  =  'GOOD' 

THEN  DO; 

SAVE_NAME   =    LHNT_NAHE; 
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SAVE_DB_NAME   =    DB_NAME; 

OBTAIN    CALC    RECORD    (DAT  A_ELEMENT)  ; 

DO    WHILE     (ERROR_STATUS    =~REC_FOUND)  ; 

OBTAIN    OWNER    SET    (DEFINED_BY)  ; 

IF    SAVE_DB_NAME    =    DB_NAME 

THEN 

ERROH_STATOS    =    'FWND'; 

ELSE 

OBTAIN  DUPLICATE  RECORD  (DATA_ELEMENT) ; 
END; 

IF     (ERROR_STATUS    ->=    '0326'    5    ERROR    STATUS    -.=    'FWND') 
THEN    CALL    IDMS_STATUS; 
IF    EHROB_STATUS    =     'FWND' 
THEN   DO; 

PUT    STRING     (HSG)     EDIT     (LMNT_NAME,'    ALREADY    EXISTS')      (2(A)); 

CALL    MESSAGES; 

LMNT_NAME    =    •     ' ; 

END; 
ELSE   DO; 

DB_NAME   =    SAVE_DB_HAHE; 

OBTAIN    CALC    RECORD     (DATA_BASE) ; 

END; 
END; 
ELSE 

LMNT_NAME   =     '     ' ; 
END    NEW_LMNT_NAME; 

NEW_CONCAT_FIELD:  PROC     (SLCT_NUM  ,MENU_ENTEY)  ; 

/*  This    module   adds   and  delates   sub-elements  of   a   concatenated  */ 

/*   data   element.      If   the   user  isn't    sure    which    DATA_ELEMENT  */ 

/*   occurrences   to   make    sub-elements,    a   blank    MENU_ENTRY   will  */ 

/*   list    all    DATA_ELENENT    occurrences    for    the    respective    DATA_  */ 

/*   BASE   occurrence.  */ 

/**********************  *************  ***************************<,,(,/ 

DCL  MENU_NUM  CHAR  (3), 

MENU_ENTRY  CHAE{69)  , 

SAVE^NAME  CHAR  (16), 

(SLCT_NUM,I)  FIXED  (3), 

STATUS  CHAR  (4)  ; 

SAVE_NAKE  =    LflNT_NAHE; 

IF     (SLCT_NUM    =    45    LMNT_TYPE   =     'CONCATENATED') 

THEN    DO; 

/*********       ADD    NEW    SOB    ELEMENT       ***********/ 
IF    MENU_ENTRY   -.=     '     ' 
THEN   DO; 

/*******    SUB    ELEMENT    SUPPLIED    VIA    MENU_  ENTRY    ******/ 
CONCAT_FIELD    =    MEMU_ENTRY; 
IF   CONCAT_FIELD    »   LMNT_NAME 
THEN    DO; 

MSG   =    'ELEMENT    NAME    S    SUB    ELEMENT    ARE    EQUAL    -    USE    MENU'; 
CALL    MESSAGES; 
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END; 
ELSE    DO; 

/**    SEE    IF    CONCAT_FIELD    IS     AN    EXISTING    DATA    ELEMENT    ***/ 

SAVE_DB_NAME  =  DB_NAME; 

LMNT_NAME   =    CONCAT_FIELD; 

OBTAIN    CALC    RECOPD     (DAT  A_EL  EMENT)  ; 

DO    WHILE     (ERROR_STATUS    =    REC_FOUND)  ; 

OBTAIN    OHNER    SET     (DEFINED    BY)  ;    CALL    IDMS_STATUS; 

IF    SAVE_DB_NAME    =    DB.   NAME 

THEN 

ERROR_STATUS    =     'FWND'; 

ELSE 

OBTAIN    DUPLICATE    RECORD     (  DAT  A_ELEMENT)  ; 
END; 

IF     (ERROR_STATUS    -.=     '0326'     S    ERROR    STATUS    -.=    'FWND') 
THEN    CALL    IDMS_STATUS; 

IF    ERROR_STAT0S   =     'FUND' 
THEN    DO;~ 

/***    VALID    DATA    ELEMENT    BUT    DOES    IT    ALREADY    EXIST    ***/ 
CALL    DUP_CK  (CONCAT_TBL,CONCAT_FIELD, STATUS)  ; 
IF    STATUS    =     'GOOD' 
THEN   DO; 

/****    SUB    ELEMENT    DOESN'T    ALREADY    EXIST       *****/ 
NUM_CONCAT   =    NUM_CONCAT    +    1; 
CONCAT_TBL(NUM_CONCAT)     =    CONCAT_FIELD; 
END; 
ELSE    DO; 

/****   SUB    ELEMENT    DOES    ALREADY    EXIST       *****/ 
PUT    STRING     (MSG)     EDIT     (CONCAT    FIELD, 
•    ALREADY    EXISTS    AS     A    SUB    ELEMENT') 
(2(A))  ; 
CALL    MESSAGES; 
END; 
LMNT_HAME    =    SAVE_NAME; 
RETURN; 
END; 
ELSE    DO; 

/**    SUB    ELEMENT    SELECTED    ISN'T    A    VALID    DATA    ELEMENT    **/ 
PUT    STRING     (MSG)     EDIT     (CONCAT_FIELD , 

■     DATA    ELEMENT    DOES    NOT    EXIST    -    USE    MENU')      (2(A)); 
CALL    MESSAGES; 
END; 
END; 
END; 

/**    LIST    ALL    DATA    ELEMENTS    TO    SELECT    A    SUB    ELEMENT    *****/ 
DISPLAYJTBL   =     •     •; 
OBTAIN    FIRST    SET     (DEFINED_BY)  ; 
IF   ERROR_STATUS    =    '03  07' 
THEN    DO;~ 

MSG   =    'NO    DATA    ELEMENTS    TO    SELECT    FROM    !'; 
CALL    MESSAGES; 
LMNT_NAME   =    SAVE_NAME; 
RETURN; 
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END; 
COONT   =    0; 

DO   WHILE     (ERROR_STATUS    =    REC_F0U!1D); 
COUNT    =    COONT    +    1; 
POT    STRING     (DISPLAY_TBL  (COUNT)  )     EDIT 

(COUNT,')        ',LMNT_NAME,'        •)      (F(3),3(A)); 
DOMAIN_TBL  (COUNT)     =    LMNT_NAME; 
OBTAIN    NEXT    SET     (DEFINED~BY) ; 
END; 

IF   ERBOR_STAT0S    -•=     '0307'    THEN    CALL    IDHS_STATUS; 
DISPLAY_TBL(COUNT+1)     =    '       X)        EXIT'; 
CALL    GEN_MENU     (MENU_NUM  ,MENU_ENTR  Y,  •  *    ADD    DATA    ELEMENT    *', 

COUNT, SLCT    NUM, 3)  ; 
IF    MENU_NUM    -.=    'X' 
THEN    DO; 

/***    VALID    DATA    ELEMENT    BUT    DOES    IT    ALREADY    EXIST    ***/ 
CALL    DUP_CK(CONCAT_TBL,DOMAIN_TBL(SLCT    NUM)  , STATUS)  ; 
IF    STATUS    =     'GOOD' 
THEN    DO; 

/****    SUB    ELEMENT    DOESN'T    ALREADY    EXIST       *****/ 
NUM_CONCAT    =    NUM_CONCAT    +     1; 

CONCAT_TBL(NUM_CONCAT)     =    DOMAIN_TBL  (SLCT    NUM); 
END; 
ELSE    DO; 

/****    SUB    ELEMENT    DOESN'T    ALREADY    EXIST      *****/ 
PUT    STRING     (MSG)     EDIT     (DOMAINJTBL  (SLCT_NUM)  , 
•     ALREADY    EXISTS    AS    A    SUB~ELEME NT' ) 
(2(A))  ; 
CALL    MESSAGES; 
END; 
END; 
END; 
ELSE   DO; 

/********       REMOVE    A   SUB    ELEMENT       ***********/ 
NUM_CONCAT    =    NUM_CONCAT    -    1; 
DO    I    =     (SLCT_NUM-4)     TO    NUM_CONCAT; 
CONCAT_TBL(I)     =    CONCAT_TBL  (1+  1)  ; 
END; 

CONCAT_TBL  (NUM_CONCAT+ 1 )     =    '     '; 
END; 
DUP_CK:  PROC (SRCH_TBL,SRCH_FLD, STATUS) ; 

/♦it***********************************  *******#*****:«#*****  #*»****/ 

/*   This   module   is   used    when   creating    a   new   concatenated   DATA_        */ 
/*  ELEMENT   occurrence   to   make   sure   that    the   same   sub-element  */ 

/*  is   not   used  twice   for   a   single   concatenated   DATA_ELEMENT  */ 

/*   occurrence.  */ 

/********#**************#****##**********###*****####**#**#**#***/ 

/**    IF    SRCH_FLD    IS    FOUND    IN"  SRCH_TBL    THEN    STATUS    IS    SET    TO      ***/ 
/**    "BAD."       IF    IT    IS    NOT    FOUND    STATUS    IS    SET    TO    "GOOD."  ***/ 

DCL  (SECHJTBL  (20)  ,SRCH_FLD)       CHAR  (16), 

STATUS  CHAR  (4)  , 

I  FIX  ED  (3)  ; 
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STATUS   =    'GOOD' ; 
DO   I   =    1    TO    50; 

IF    SRCH_TBL(I)     =    SRCH    FLD 
THEN    DO; 

STATUS   =    'BAD' ; 
RETURN; 
END; 
END; 
END    D0P_CK; 

LMNT_NAME    =    SAVE_NAME; 
END    NEW_CONCAT_FIELD; 
END    NEW_LMNT; 

CHG_DEL_LMNT:       PROC     (M  ENU_ENTRY)  ; 

/  **  *******************  ****************************,*»***  .m,,,*.,,,,.^ 

/*  This    module   changes    and   deletes   DATA_ELEMENT   fields    of  the        */ 
/*    "current"    DATA_ELEMENT    occurrence.  */ 

/*******************  ****************  ********************»lt:t*+#<t,%^ 

DCL  MENU_ENTRY  CHAR(69); 

MSG    =    'CHG_DEI._I.MNT    TO    BE    COMPLETED'; 

CALL    MENU_HEAD; 

DISPLAY     PPRESS    ENTER    TO    CONTINUE')     REPLY    (ENTER_KEY)  ; 

END      CHG_DEL    LMNT; 


/********** ********************************************** 


*******/ 


LMNT_DEF_BTN:  PROC     (MENU_ENTR  Y,L  MNT_DEF)  ; 

/************************  **************************  ****#<,^  +  »#:(t^#^ 

/*  This    module   allows   the   data   base   desiqner   to   enter   a    data        */ 
/*   element    definition   for   the   "current"    DATA_ZLEMENT  */ 

/*   occurrence.  */ 

/********************** ************** ** *************************/ 

DCL  MENU_ENTRY  CHAR  (69), 

LMNT_DEF  CHAR  (55)  ; 

IF    MENU_ENTRY    =    '     ' 
THEN    DO; 

MSG    =    '**       ENTER    ELEMENT    DEFINITION    **'; 

CALL    MENU_HEAD; 

DISPLAY     ("•  ====>')     fiEPLY     (LMNT_DEF)  ; 

END; 
ELSE 

LMNT_DEF    =    MENU_ENTRY; 
END    LMNT_DEF_RTN; 
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LMNTJTYPE_RTN:  PEOC    (MENU_EHTRY,  LHNT_TYPE)  ; 

/*    This    module    updates    the    LMNTJTYPE    field   in   the   DATA_ELEMENT  */ 

/*   structure.      If  no   MENU_ENTRY   parameter   is"  inputted   into   this  */ 

/*    module,    a   list  of    possible   values    will   be   displayed   for   the  */ 

/*    data   base  designer   to  make   a   decision.  */ 

DCL  MENU_ENTRY  CHAR  (69), 

LMNTJTYPE  CHAR  (17), 

THE_VALOE  CHAR  (16)  , 

I  FIXED  (2)  ; 

/*         LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE  */ 

DISPLAY_TBL(1)  =  '1)  CHARACTER  ';  DOMAIN    TBL  (1  )=' CHARACTER         •; 

DISPLAYJTBL(2)  =  '2)  NUMERIC  ';  DOMAIN_TBL  (2)  *•  NUMERIC  •; 

DISPLAY_TBL(3)  ='  3)  CONCATENATED'  ;  DOMAIN_IBL  (3)  =  ' CONCATENATED  •  ; 

DISPLAY_TBL(4)  =  'X)  EXIT  •; 

/*    IF    NO    MEND_ENTRY    THEN    CALL    ROUTINE   TO    SELECT    A    VALID    ENTRY    */ 

THE_7ALDE  =    LMNT    TYPE; 
LMNT_TYPE    =    MENU_ENTRY; 
IF    LBNT_TYPE    =    '     ' 
THEN    DO; 

CALL    SLCTJVALUE     (DISPLAYJTBL, DOMAIN  JTBL ,THE_VALUE, 
■**    ELEMENT    TYPE    VALUES    **'  ,3)  ; 

LMNTJTYPE    =    TUE_VALUE; 

END; 
ELSE   DO; 

/*      THERE    WAS    A    MENU_ENTRY    —    RETURN    IF    VALID    MENU_ENTRY  */ 

DO    I   =    1    TO    3; 

IF    DOMAIN_TBL (I)     =    LMNTJTYPE 
THEN 

RETURN; 
END; 

/*    THERE    MUST    HAVE    BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WRITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY    */ 

PUT    STRING     (MSG)     EDIT     (LMNTJTYPE,1     IS    NOT    AN    ACCEPTABLE    *, 

•VALUE    FOR    ELEMENT    TYPE    —    USE    MENU')         (3(A)); 
CALL    MESSAGES; 
CALL   SLCT_VALUE    (  DISPLAYJTBL  ,  DOMAIN  JTBL, THE    VALUE, 

'**    ELEMENT    TYPE    VALUES    ***",3); 
LMNTJTYPE   =    THEJVALUE; 
END; 
END    LMNTJTYPE_RTN; 
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TOTAL_SIZE_RTN:  PROC    (KENU_ENTRY  ,TOTAL_SIZE)  ; 

/**************** ************************************************/ 
/*  This  module  updates  the  TOTAL_SIZE  field  in  the  DATA_ELEMENT  */ 
/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data   base  designer   to   make  a  decision.  '  */ 

/*****  ****************  ************************************„**,.  #<t/, 

DCL         MENU_ENTRY  CHAR  (69), 

TOTAL_SIZE  PICTURE  '(3)9', 

DIGITS  CHAR(IO)     INIT     ('0123456789'), 

I  FIXED  (3); 

IF    MENU_ENTRY    =    '     • 
THEN   DO; 

POT    STRING     (MSG)     EDIT 

('ENTER    TOTAL    SIZE    OF    •  ,  LHN  T_NAKE)      (2(A)); 

CALL    MESSAGES; 

RETURN ; 

END; 

I   =    69; 

DO    WHILE     (SUBSTR(MENU    ENTRY, 1,1)     =    '     '); 
1    =    1-1; 

END; 

IF    I    >   3 

THEN    DO; 

MSG    =    'ENTRY    TO    LARGE*; 
CALL    MESSAGES; 
RETURN; 
END; 

IF    VERIFY(SUBSTR(MENU    ENTRY,  1  , 1)  ,  DIGITS)     =    0 
THEN    DO; 

DO    WHILE     (SUBSTR(MENU_ENTRY,3,1)     =    •     •); 

SUBSTR(MENU_ENTRY,3,1)    =    SUBSTR  (MENU_ENTRY,  2,  1 )  ; 
SUBSTR(HENU_ENTRY,2,1)    =    SUBS  TR  (MENU_ENTRY,  1,  1)  ; 
SUBSTR(MENU_ENTRY,  1,1)     =    '     ■  ; 
END; 
GET    STRING     (SUBSTR  (MENU    ENTRY,  1,3)  J     EDIT 

(TOTAL_SIZE)     (F(3)  )  ; 
END; 
ELSE    DO; 

MSG  =  'NON  NUMERIC  ENTRY  -  REENTER'; 
CALL  MESSAGES; 
END; 
END  TOTAL_SIZE_PTN; 
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FRCTN_SIZE_RTN:  PROC    (MENU_ENTHY  ,FRACTION_SIZ  E)  ; 

/***************************** ***********************************/ 

/*  This  module  updates  the  FRCTN_SIZE  field  in  the  DATA.ELEMENT  */ 
/*  structure.  If  no  MENU_ENTEY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*    data   base  designer    to  make   a   decision.  */ 

/********************************#*******************************/ 

DCL  NENUJ3NTRY  CHAE(69), 

FRACTION_SIZE  PICTORE         '(1)9'. 

DIGITS  CHAR(10)     INIT     (■0  123456789'), 

I  FIXED(3); 

IF    HEN0_ENTRY    =    •     • 
THEN    DO; 

POT    STRING     (HSG)     EDIT 

{•ENTER    FRACTION    SIZE    OF    ',LMNT_NAME)      (2(A)); 

CALL    MESSAGES; 

RETURN; 

END; 

I    =    69; 

DO    WHILE     (SUBSTR(MENU    ENTRY, 1,1)     =    '     '); 
1=1-1; 

END; 

IP   I    >    1 

THEN   DO; 

HSG  =  'ENTRY  TO  LARGE'; 
CALL  MESSAGES; 
RETURN; 
END; 

IF  VERIFY  (SOBSTR  (MENO_ENTRY,  1,1)  .DIGITS)  =  0 
THEN  DO; 

DO  WHILE  (SDBSTR(MENU_ENTRY,3,  1)  =  >  '); 

SUBSTR(MEN0_ENTRY,3,1)    =    SUBSTR(MENU    ENTRY, 2,1); 
SUBSTH(MENU_ENTRY,2,1)     =    SrjBSTE  (MEHU~ENTRY,  1  , 1 )  ; 
SOBSTR  (MENO_ENTRY,  1,1)     =    '     ■; 
END; 
GET    STRING     (SUBSTR  (MENU_ENTRY  ,  1  ,  3)  )     EDIT 

(FRACTION_SIZE)      (F  (3 j")  ; 
END; 
ELSE   DO; 

HSG   ■    'NON    NUMERIC    ENTRY    -    REENTER'; 
CALL    MESSAGES; 
END.; 
END    FRCTN_SIZE_RTN; 
END    LMNT_HPDATE; 
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ORD_0PDATE:       PROC  (HENU_ENTRY)  ; 

****************** *************************************** 

This    module   displays  all   existing   RE_CORD  occurrences 

for   the   "current"   DATA_BASE  structure   and   allows   the   user 

to    add  a   new   RE_CORD   occurrence,    chanqe  and  existinq 

RE_CORD    occurrence,    or   delete    an    existinq    RE_CORD 

occurrence. 

********************  ************************************* 

RECORD  UPDATE 


NEW_RECORD 
+ + 

I     NEH_  J 

I     REC_NAME    | 
+ + 


I     REC_  | 

I     NEW_MENn     | 


|     CALC_ 
I     VIA_NEW 


REC_  | 

LAST    NEW       I 


I       LCTN_  | 

I        MODE_RTN       | 


I       R  EC_  | 

I        DUP_RTN       | 


CHG_DEL_REC 

* *■  + +  ♦ +       + + 

I     EEC-  I  1     HEC_  |  |     CALC_  ||     CHG  | 
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*/ 

*/ 

*/ 

*     */ 
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*/ 
*/ 
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*/ 
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V 

*/ 
*/ 
*/ 
*/ 

*****/ 


DCL  MENIJ_ENTRY  CHAR  (69), 

(SLCT_NU:i,NUM    REC_LNNTS)  FIXED    DSC(3), 

MENU_NtJM  CHAR  (3), 

REC_LMNT_TBL  (500)  CHAR  (16); 

IF    MENU_ENTEY    -■=    '     • 
THEN   DO; 

REC_NAME   =    MENU_ENT2Y; 

SAVE_DB_NAME    =    DB_NAME; 

OBTAIN  CALC  RECORD  (BE_CORD)  ; 

DO    WHILE     (ERROR_STATUS    =    REC_FOUND); 

OBTAIN    OWNER    SET    ( DIVIDED_  INTO)  ;       CALL   IDHS    STATUS; 

IF    SAVE_DB_NAME    =    DB    NAME 

THEN 

ERROR_STATUS  =  • FWND'; 
ELSE 

OBTAIN  DUPLICATE  RECORD  (RE_CORD); 
END; 

IF     (ERROR_STATUS    -.=     '0326'     5    ERROR    STATUS    -.=    "FBND'J 
THEN    CALL   IDMS_STATUS; 


132   - 


IF     (ERROR_STATUS    =    'FWND') 
THEN    DO; 

MENU_ENTRY    =    •     ' ; 

CALL    CHG_DEL_REC     (MENU_ENTRY)  ; 

RETURN; 

END; 
ELSE    DO; 

DB_NAME    =    SAVE_DB_NAME;  /***#*****    NEW    ********/ 

OBTAIN   CALC    RECORD     (DATA_BASE)  ;    /******    NEW    ***/ 

PUT    STRING     (HSG)     EDIT     (MENU_ENTRY, 

•    IS    NOT    AN    EXISTING    RECORD')      (A  (16), A); 

CALL    MESSAGES; 

END; 
END; 

/*  LOAD    TABLE    WITH    RECORDS       NAMES  */ 

MENU_NUM    =     '     •  ; 
DO    WHILE    (HENU_NUB    --  =     'X'): 
DISPLAY_TBL    =     '     • ; 

PUT    STRING     (DISPLAY_TBL(1))     EDIT     (M)        CREATE    RECORD') 

(X(4)  ,A)  ; 
PUT    STRING     (DISPLAY_TBL(2)  )     EDIT     ('2)        3NF    ALL    ELEMENTS') 

(X{4)  ,A)  ; 
PUT    STRING    (DISPLAY_TBL(3)  )     EDIT     ('3)        3NF   NEW    ELEMENTS') 

(X(4),A)  ; 
OBTAIN    FIRST    SET     (DI  VIDED_IN  TO)  ; 
IF    ERROR_STATUS    -.=     '0307'" 
THEN    CALL    IDMS_STATUS; 
COUNT    =    3; 

DO    WHILE     (ERROR_STATUS    =    REC_FOUND)  ; 
COUNT    =    COUNT~+    1; 
PUT    STRING     (DISPLAY_TBL (COUNT) ) 
EDIT    (COUNT,1)         ',REC_NAME) 
(X(2)  ,F(3),2(A)  )  ; 
DB_KEY_TBL  (COUNT)     =    DBKEY; 
OBTAIN    NEXT    SET     ( DIVIDED_I  NTO)  ; 
IF    ERROR_STATUS    -.=     '0307' 
THEN    CALL    IDMS_STATDS; 
END; 

PUT    STRING     (DISPLAY_TBL(COUNT    ♦     1)) 
EDIT     {'  X)        EXIT*)      (A); 

/*  DISPLAY    MENU         /       ACCEPT    EDIT    REPLY         */ 

CALL    GEN_MENU     (MEND_NUM,  MENU_ENTRY, 

'  **    RECORD    UPDATE    ** ' , COUNT, SLCT_ HUM, 3) ; 

/*      CONTINUE    TO    UPDATE    RECORDS    UNTIL    EXIT         */ 

IF    MENU_NUM    =    'X' 
THEN 

RETURN; 
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IF    SLCT_NUM    =     I    THEN 

CALL    NEK_RECORD     (MENU    ENTRY); 
ELSE    IF    SLCT_NUM    =    2    THEN 

CALL    ALL_LMNTS_3NF; 
ELSE    IF    SLCT_NUM    =    3    THEN 

CALL    NEW_LMNTS_3NF; 
ELSE    DO; 

REC_NAME    =    SUBSTR(DISPLAY_TBL(SLCT    ROB), 9, 16); 

OBTAIN    RECORD     (RE_CORD)     DBKEY     (DB_KEY_TBL  (SLCT_NUH)  )  ; 

CALL    IDMS_STATUS; 

CALL    CHG_DEL_REC     («ENn_ENTEY)  ; 

END; 
END; 

NEW_RECORD:       PROC  (MENU_EN  TR  Y)  ; 

/******#******  ********************************  *********„*,,,.  j.^,,.,,^ 

/*   This    module   establishes   a    new    RE_CORD   occurrence   by  */ 

/*   defaulting   the  EE_CORD   occurrence   fields   and  calling    the  */ 

/*    modules    to    update    the   fields   based   on    the   user's    M2NU_ENTBY.    */ 
/*   Once   updating    is   complete,    the   new    RE_CORD   occurrence   is  */ 

/*  stored.  */ 

/**************** ************************************************/ 

DCL  MENU_ENTRY  CHAR  (69)  , 

MENU_NUM  CHAR  (3), 

(SLCT_NOft,I)  FIXED    DEC     (3); 

/*  INITIALIZE    AND    DEFAULT    RECORD    FIELDS  */ 

2EC_LMNT_TBL    =    •     ' ; 
NOM_REC_LMNTS    =    0; 
RE_COED   =    '     '  ; 
REC_NA!1E    =     •     '  ; 
REC_STRG_MODE    =    • F' ; 
REC_DOP_OPTION   =    'DN1; 
REC_LCTN_HODE    =    'CALC; 
REC_CALC_VIA   =    '     • ; 

/*      HAS    A    RECORD    NAME    BEEN    PROVIDED    FROM    SECONDARY    MENU  */ 

IF    MENU_ENTHY    =    '     • 
THEN 

CALL    REC_NEW_MENU     (MENU_NU?1  ,  MEN  U_EN  TRY,  SLCT    NOM)  ; 
ELSE 

MENU_NUM    =    *V  I 

/*      ADD    RECORD    ATTRIBUTES    UNTIL    EXIT  */ 

DO    WHILE     (MEND"_NUM    -.=    'X'); 
IF    MENU_NUM    =    ■ T     THEN 

CALL    NE»_REC_NAME    ( MENU_2NTRY  ,REC_NAM  E)  ; 
ELSE    IF    MEHu_NUH    =    *2'     THEN 

CALL    STRG_MODE_RTIJ     (MENU_ENTE  Y,  R2C_STRG_M0DE)  ; 
ELSE    IF    MENU_NUM    =    '3'    THEN 
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CALL    LCTN_MODE_RTN     (MENU    ENTRY,  REC_I.CTN_MODE)  ; 
ELSE    IF    REC_LCTN_MODE    =    'CALC 
THEN    DO; 

IF    MENU_NUM    =     ■  4  '    THEN 

CALL    REC_DIJP_RTN     (M  EN  U_ENTR  Y,REC_DUP_OPTION)  ; 
ELSE    IF    MENU_NUM    =     '5'    THEN 

CALL    CALC_VIA_NEW     (MENU_ENTRY,  REC_CALC_VIA)  ; 
ELSE    IF    MENU_NUM    >=    '6'    THEN 

CALL    REC_LMNT_NEW     (SLCT_NUM  ,MENU_ENTRY)  ; 
END; 
ELSE   DO; 

IF    MENU_NUM    =    •«'    THEN 

CALL    CALC_VIA_NEW     (MENU_ENTRY,EEC_CALC_ VIA) ; 
ELSE    IF    MENU_NUM    >=     '5'    THEN 

CALL    REC_LMNT_NEW     (SLCT_NUM  ,MEN  U_ENTRY)  ; 
END; 
CALL    REC_NEW_MENU     (MENU_NUM,  MEN  U_ENTRY,SLCT    NUM)  ; 
END; 

IF    REC_NAME    =     '     ' 
THEN    DO; 

MSG    =     'RECORD    NAME   IS    BLANK    —    NO    ADD    MADE'; 

CALL    MESSAGES; 

RETURN; 

END; 

STORE  RECORD  (RE_CORD)  ; 

DO    I    =    1    TO    NOM_REC_LMNTS; 

LHNT_NAME    =    REC_LMNT_TBL  (I)  ; 

SAVE_DB_NAME    =    DB_NAME; 

OBTAIN    CALC    RECORD     (DAT A_ELEMENT) ;       CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (DEFINED_BY) ;  CALL    IDMS    STATUS; 

DO    WHILE     (SAVE_DB_NAME    -«■    DB_NAME)  ; 

OBTAIN    CALC   RECORD     (DATA_ELEM ENT) ;       CALL    IDMS_STATUS; 
OBTAIN    OWNER    SET    (DEFINED    BY) ;  CALL    IDMS_STATUS; 

END; 

STOBE    RECORD    (LMNT_REC)  ;       CALL    IDMS    STATUS; 
END; 

NEW_REC_NAME:       PROC     (M  ENU_ENTRY,  R  EC_NAME)  ; 
/*************************************************************$*#/ 

/*   This    module   allows   the   user  to   assign    a   record  name  to   a  */ 

/*   newly   created   RE_CORD   occurrence.      Before   the   record    name  */ 

/*  is   accepted,    a   check   is   made  -to   verify   it    does    not    already  */ 

/*   exist.  */ 

DCL  MENU_ENTRY  CHAR  (69), 

(REC_NAKE«SAVE_NAME)  CHAR(16), 

STATUS  CHAR  (4)  ; 

REC_NAME    =    MENU_ENTPY; 

CALL    EDIT_NAME    (REC_NAME,  ST  ATUS)  ; 
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IF  STATUS  =  'GOOD' 
THEN  DO; 

SAVE_NAME    =    REC_NAJ1E; 

SAVE_DB_NAME   =    DB_NAME; 

OBTAIN    CALC    RECORD    (RE_CORD)  ; 

DO    WHILE     (ERR0R_STATI1S    =    PEC_FOUND)  ; 

OBTAIN    OWNER    SET    ( DIVIDED_INTO) ;       CALL    IDMS    STATUS; 

IF    SAVE_DB_NAME    =    DB_NAME 

THEN 

ERROR_STATUS  =  'FWND'; 
ELSE 

OBTAIN  DUPLICATE  RECORD  (RE_CORD)  ; 
END; 

IF  (ERBOR_STATUS  -•=    '0326'  E  ERROR  STATUS  -.=  <  FWND' ) 
THEN  CALL  IDMS_STATUS; 

IF  ERROR  STATUS  =  'FWND' 
THEN  DO;~ 

PUT  STRING  (HSG)  EDIT  (REC_NAHE,'  ALREADY  EXISTS  '  )  (2  (  A)  )  ; 

CALL  MESSAGES; 

REC_NAME  =  •  ■ ; 

END; 
ELSE  DO; 

DB_NAME  =  SAVE_DB_NAME; 

OBTAIN  CALC  RECORD  (DATA  BASE) ; 

END; 
END; 
ELSE 

REC_NAME  =  '  * ; 
END  NEW_REC_NAME; 

REC_NEW_HENU:       PROC     (MENU_N  UM,MEN  U_ENTR  Y,SLCT_NUM)  ; 

/*»«*«*»***»*»***********»»»«**»****»*♦♦****»**»»»♦*(,»»»«*»*»»»»/ 

/*  This    module   displays  the    RE_CORD   fields   that    can    be  updated      */ 
/*   for    a    new   RE_CORD   occurrence.       It    also   displays   the    DATA  */ 

/*   ELEMENT    occurrences   that   are  liked   to   this    RE_CORD   occurrence*/ 
/*  for   updating    (i.e.,    add   or  delete).  */ 

/*****  ***********************#*#****#<,#***!),*  ************  *********/ 

DCL        MENU_NUM  CHAR (3) , 

MENU_ENTRY  CHAR(69), 

(I,SLCT_UUM)  FIXED  DEC  (3)  ; 

/*   LOAD  DISPLAY  TABLE   */ 

DISPLAY_TBL    =    ■     •  ; 

PUT    STRING     (DISPLAY_TBL  (1))     EDIT 

(•1)     RECORD    NAME:     •  ,REC_NAME)    (2(A)); 
PUT    STRING     (DISPLAY_TBL(2)  )     EDIT 

(*2)     RECORD    STORAGE   BODE:     • ,  RBC_STRG_HODE)   (2(A)); 
PUT    STRING     (DISPLAY_TBL(3)  )     EDIT 

('3)     RECORD    LOCATION    MODE:    •  ,  REC_LCTN_MODE)  (2  ( A)  )  ; 
IF    REC_LCTN_MODE    =    'CALC 
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THEN    DO; 

COUNT    =   7; 

PUT    STRING     (DISPLAY, TBI,  («)  )     EDIT 

(■4)     EECOBD    DUPLICATE    OPTION:     •  ,EEC_DUP_OPTION)   (2(A)); 
PUT    STRING     (DISPLAY_TBL  (5))     EDIT 

(•5)     RECORD   CALC   KEY    OR    VIA    SET:     '  ,REC_CALC    VIA)  (2  (A)); 
PUT   STRING     (DISPLAY_TBL  (6))     EDIT 

(•6)     ADD    DATA    ELEMENT    TO    '  ,  REC_NAME)  (2  ( A)  )  ; 
END; 
ELSE    DO; 
COUNT   =    6; 
PUT    STRING     (DISPLAY_TBL(4))      EDIT 

{•!»)     RECORD   CALC    KEY    OR    VIA    SET:     '  ,  REC_CALC_VIA)  (2(A))  ; 
PUT    STRING     (DISPLAY_TBL  (5))     EDIT 

('5)     ADD    DATA    ELEMENT    TO    •  ,  REC_NAME)  (2  ( A)  )  ; 
DISPLAY_TBL  (6)     =    'DELETE    DATA    ELEMENT    .     .     .'; 
END; 
DO    I    =    1    TO    NUM_PEC_LMNTS; 
COUNT    =    COUNT    ♦    1; 

PUT   STRING     (DISPLAY_TBL  (COUNT)  )     EDIT 
(COUNT- 1,')     '  ,REC_LMNT_TBL(I))      (X  (2)  ,  F  (3)  ,  2  (A)  )  ; 
END; 

DISPLAY_TBL  (COUNT*  1)  =  'X)  EXIT'; 

CALL    GEN_HENU     (MENU_NUM,  MENU_ENTR Y,  '  **    CREATE    NEK    RECORD    **', 
COUNT-1,SLCT_NUH,2)  ; 
.    END    REC_NEB_MENU; 

CALC_VIA_NEH:  PROC     (MENU_ENTR  Y  ,R  EC_CALC_VIA)  ; 

/**********  ******  *******************  *************  *****  ******  *****/ 
/*  This  module  assiqns  a  value  to  the  REC_CALC_VIA  field  of  a  */ 
/*    new   HE_CORD   occurrence.       Because    it    is   a    new   RE_CORD  */ 

/*  occurrence,  it  cannot  be  a  member  of  any  set  at  this  time.  */ 
/*  Thus,  a  proper  via  set  value  is  not  allowed.  The  calc  value  */ 
/*   can    be  any   DATA_ELEMENT    occurrence  associated    with   this  */ 

/*    RE_CORD    occurrence.  */ 

/**************** *************** ************************ *********/ 

DCL  MENU_NUM  CHAR  (3)  , 

HENU_ENTRY  CHAR  (69)  , 

REC_CALC_VIA  CHAR  (16), 

(SLCT_NUM,I)  FIXED    DEC(3); 

/*  VIA    SET    IS    NOT    POSSIBLE   FOR    A    NEW    RECORD  */ 

IF    REC_LCTN_MODE    =    'VIA' 
THEN   DO; 

msg  =  'record  is  not  member  of  any  set  -  ', 

'no  acceptable  value' ; 
Call  messages; 

RETURN; 
END; 

/*    SEE    IF    flENU_ENTRY    IS    A    RECORD    DATA    ELEMENT       */ 

DO    I    =    1    TO    NUM_EEC_LMNTS; 
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IF    HEC_LMNT_TBL(I)     =    HENU_ENTFY 
THEN   DO; 

REC_LCTN_MODE    =     'CMC;  /*       III    CASE    IT    WAS    BLANK       */ 

REC_CALC_VIA    =    MENU_ENTRY; 
RETURN; 
END; 
END; 
DISPLAY_TBL(I)     =     •       X)        EXIT'; 

/*      ARE    THERE    DATA    ELEMENTS    FOR    A    CALC    KEY  */ 

IF    NUM_REC_LMNTS    =    •  0* 
THEN   DO; 

MSG    =    'RECORD   CONTAINS    NO    DATA    ELEMENTS    -    "     ', 
•NO    ACCEPTABLE    VALUE'; 

CALL    MESSAGES; 

RETURN; 

END; 

/*      DISPLAY    DATA    ELEMENTS    FOR    CALC    KEY    SOLUTION  */ 

CALL    GEN_HENtI     (MENU_NUM,  M  EI!IJ_ENTR  Y,  '  **    SELECT    CALC    KEY    **  ■  , 

NDM    REC_LMNTS7SLCT_NUM,3)  ; 
IF    MENU_NUM    =     'X' 
THEN 

RETURN; 
EEC_CALC_VIA   =    REC    LMNT_TBL  (SLCT_NUM)  ; 
END    CALC_VIA_NEW; 

REC_LMNT_NEH:       PROC     (SLCT_NUM,  MENU_E  NT  RY)  ; 
/****************************###*****,),**»,  *******»*#*****#****»#»/ 

/*   This   module   links  existing   DATA_ELEMENT  occurrences   to   a  */ 

/*   new    RE_CORD    occurrence.       If   the~MENU_ENTRY    parameter    does  */ 

/*   not   contain   a    valid    data    element    name   then   a   complete    list  */ 

/*   of    data   element   names  is   displayed   for   the   user   to   select  */ 

/*   from.  if, 

/*********************  *********♦**************„#**,.„,,<,,,;<,*  *«*******/ 

DCL  MENU_NIJM  CHAR(3), 

MENU_E!!TRY  CHAR(fc9), 

(SLCT_NUM,  START)  FIXED  (3)  J 

IF     (SLCT_NUM    =    5    |      (SLCT_NUM    =    6    £    RSC_LCTN_MODE    =    'CALC')) 
THEN    DO; 

IF    MENU_ENTRY   -•=     '     • 
THEN    DO? 

LMNT_NAME    =    MENU_ENTRY; 
SAVE_DB_NAME    =    DB_MAME; 
OBTAIN    CALC   RECORD     (DATA    ELEMENT)  ; 
DO    WHILE     (ERROR_STATUS    =~REC_FOUHD) ; 

OBTAIN    OWNER    SET     (DEFINED_BY)  ;       CALL    IDMS_STATUS; 

IF    SAVE_DB_NAME    =    D3_NAME 

THEN 

ERROR_STATUS    =    'FUND'; 
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ELSE 

OBTAIN    DUPLICATE    RECORD    (  DATA_ELEKENT)  ; 
END; 

IF     (ERROR_STATUS    -=    '0326'     £    ERROR_STATUS    -■=    'FWND') 
THEN    CALL    IDMS_STATUS; 
IF    EBROR_STATUS    =    'FUND' 
THEN    DO;~ 

NUM_R2C_LMNTS    =    NUM_REC_LMNTS    +     t; 

REC_LMNT_TBL(NUM_REC_LMNTS)     =    LMNT_NAME; 

RETURN; 

END; 
ELSE    DO; 

POT    STRING     (MSG)     EDIT 

(LMNT_NAME, 

•    DATA    ELEMENT    DOES    NOT    EXIST    -    USE    MENU')  (2(A)); 

CALL    MESSAGES; 

END; 
END; 

/*******       LIST    ALL    DATA    ELEMENTS    TO    SELECT    FROM  *******/ 

DISPLAY_TBL    =    »     ' ; 

OBTAIN    FIRST   SET     (DEFINED_BY)  ; 

IF    ERROR_STATUS    =     '0307  • 

THEN    DO; 

MSG    =    'NO    DATA    ELEMENTS    TO    CHOOSE    FROM!'; 

CALL    MESSAGES; 

RETDBN; 

END; 
COUNT    =    0; 
DO    WHILE     (ERROR_STATUS    =    REC_FOUND)  ; 

COUNT   =   COUNT~+     I; 

PUT    STRING    (DISPLAY_TBL  (COUNT)  )     EDIT 

(COUNT,')        ',LMNT_NAME,  '        • )   (F  (3)  ,  3  (A)  )  ; 

DOMAINJTBL  (COUNT)    =    LMNT_NAME; 

OBTAIN    NEXT    SET     (DEFINED_BY)  ; 
END; 

IF    ERSOR_STATUS    -■=    '0307' 
THEN    CALL   IDMS_STATUS; 

DISPLAY_TBL(COUMT+1)     =     •       X)        EXIT"; 
CALL    GEN_MENU     (MENU_NUM  ,MEN  U_EN  TR  Y, 

•**    ADD    DATA    ELEMENT    TO    A    RECORD    **• , COUNT, SLCT_ NUM. 3) ; 

IF    MEND_NUM    -.=     'X' 
THEN    DO? 

NUM_REC_LMNTS    =    NUM_REC_LMHT    +     1 ; 

REC_LMNT_TBL(NUM_PEC_LMNTS)     =    DOM AIN_TBL  (SLCT_NUM)  ; 
END; 
END; 
ELSE    DO; 

NUM_REC_LMNTS    =    NUM_REC_LMNT    -    1; 

IF    REC_LCTN_MODE    =    'CALC 

THEN 

START   =    SLCT_NUM    -    ft; 
ELSE 
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START   =    SLCT_NUM    -    5; 
DO    I    =    START    TO    NUM_REC_LMNTS ; 

REC_LMNT_TBL  (I)     =    REC_LMNT_TB L (1+ 1 ) ; 
END; 
END; 
END    REC_LMNT_NEW; 
END    NEW_RECORD; 

CHG_DEL_REC:       PROC    (MENU_ENTRY)  ; 

/*  This    module   chanqes    and   deletes   RE_CORD   fields   of   the  */ 

/*   "current"  RE_CORD   occurrence.  */ 

DCL  DEL_SW  CHAH(l), 

SAVE_NAME  CHAR{16)  , 

MENU_NUM  CHAR  (3), 

MENU_ENTRY  CHAR  (69)  ; 

IF    MENU_ENTRY    =    'DELETE' 
THEN    DO; 

FIND    CURRENT    RECORD    (RE_CORD) ;  CALL    IDMS    STATUS; 

ERASE    RECORD    (RE_CORD)     PERMANENT;     CALL    IDMS~STATUS; 

RETURN; 

END; 

SAVE_NAME   =    REC_NAHE; 

CALL    REC_CHG_MENU     ( MENU_NUM .MENU    ENTRY, SLCT    SDH)  ; 
DO    WHILE     (MENO_NUM   -•=    'X'); 
IF    HENU_NUM    =    '1'     THEN 

CALL    CHG_R2C_NAME    (MENU_ENTRY  ,REC_NAME)  ; 
ELSE    IF    MEN0_NUM    =    '2'     THEN 

CALL    STRG_MODE_RTN     (MENU    ENTRY, PEC_STRG_MODE) ; 
ELSE    IF    MENU_NUM    =     '3'    THEN 

CALL    LCTN_MODE_RTN     (MEN  U_ENTR  Y,REC_LCTN_MODE)  ; 
ELSE    IF    REC_LCTN_MODE    =     'CALC 
THEN   DO; 

IF    MENU_NUM    =    ■ 4'    THEN 

CALL    REC_DUP    RTN     (NENU_ENTRY, REC_DU P    OPTION); 
ELSE    IF    MENU_NUM    =     '5'    THEN 

CALL    CALC_VIA_CHG     (MENU_ENTRY,REC_CALC_ VIA) ; 
ELSE    IF    MENU_NUM    >=     '6'    THEN 

CALL    REC_LtlNT    CHG     (SLCT_NUM  ,MENU_ENTP  Y)  ; 
END; 
ELSE   DO; 

IF    MENU_NUM    =    ' U'    THEN 

CALL    CALC_VIA_CHG     (MENU_ENT  RY  ,  REC_CALC_VIA)  ; 
ELSE    IF    MENU_NUM    >=    •  5'    THEN 

CALL    REC_LMNT_CHG     (SLCT_NUM  ,MENU_ENT3Y)  ; 
END; 
CALL    REC    CHG_MENU     (MENU_NUM , MENU    ENTRY, SLCT_NUM) ; 
END; 


IF    REC    NAME 
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THEN    DO; 

CALL    CLRSCR; 

CALL    BLANK_LINE(5)  ; 

DISPLAY    ('CONFIRM    DELETE    BY    TYPING    "D"1); 

CALL    BLANK_LINE{5) ; 

DISPLAY    ('=====>')        REPLY     (DEL_SW)  ; 

IF    DEL_SW    =     'D' 

THEN    DO; 

FIND    CURRENT    RECORD     (RE_CORD)  ;  CALL    IDMS_STATUS; 

ERASE    RECORD     (RE_CORD)     PERMANENT;     CALL    IDMS^STATUS; 

RETURN; 

END; 
ELSE    DO; 

nSG    =    'DELETE    REQUEST    ABORTED'; 

CALL    MESSAGES; 

REC_NAME    =    SAVE_NAME; 

END; 
END; 
ELSE   DO; 

FIND    CURRENT    RECORD     (RE_CORD) ;  CALL    IDMS_STATUS; 

MODIFY    RECORD     (RE_CORD) ;  CALL    IBMS_STATUS; 

END; 

CHG_REC_NAME:  PROC     (M  ENU_ENTR  Y,R  EC_NAME)  ; 

/*   This    module   changes    the   record   name   of   the    "current"    RE_COSD    */ 
/*   occurrence   based   on    the   MENU_ENTRY.  »/ 

/ft****************************************************** 9********/ 

DCL  MENU_ENTHY  CHAR(fc9), 

REC_NAME  CHAR  (16)  , 

STATUS  CHAR  («)  ; 

REC_NAME   =    MENU_ENTBY; 

CALL    EDIT_NAME    ( REC_NAME,  STATUS)  ; 

IF  STATUS  =  'GOOD' 

THEN  DO; 

IF    SAVE_NAME   =    REC_NAME 
THEN 

ENTER_KEY    =    ■     • ; 
ELSE   DO; 

SAVE_DB_NAME    =    DB_NAME; 

OBTAIN    CALC   RECORD     (RE_CORD)  ; 

DO    WHILE     (ERROR_STATUS    =    REC_FOUND)  ; 

OBTAIN    OWNER    SET     (DIVIDED_INTO) ;       CALL    IDMS_STATUS; 

IF    SAVE_DB    NAME    =    DB_NAME 

THEN 

ERROE_STATUS    =    'FWND'; 
ELSE 

OBTAIN    DUPLICATE    RECORD     (RE_CORD)  ; 
END; 

IF     (ERROR_STATns    -=    '032f.'     S    ERROR_STATUS    -.=     'FWND') 
THEN    CALL    IDMS_STATUS ; 

-     1«1    - 


IF    ERROR_STATUS    =    'FWND' 
THEN   D0;~ 

POT    STRING     (MSG)     EDIT    (REC    NAME,'     ALREADY    EXISTS" )  (2  ( A)  )  ; 
CALL    MESSAGES; 
HEC_NAME   =    SAVE_NAME; 
END; 
ELSE   DO; 

DB_NAME    =    SAVE_DB_NABE; 

OBTAIN    CALC    RECORD     (DATA    BASE)  ; 

IF    REC_NAME    -i=    ■     ' 

THEN 

SAVE_NAHE    =    REC_NAME; 
END; 
END; 
END; 
ELSE 

REC_NAME    =    SAVE_NAHE; 
END   CHG_REC_NA11E; 

REC_CHG_MENU:  PROC     (MENH_N  tJM  ,MENU_ENTR  Y,SLCT_NUM)  ; 

/********************* ********************************** ^t***,^ 

/*  This  module  displays  the  RE_CORD  fields  that  can  be  updated  */ 
/*  for  an  existing  RE_CORD  occurrence.  It  also  displays  the  */ 
/*   DATA_ELEHENT    occurrences    that    are    linked    to    this    RE_CO-RD  */ 

/*   occurrence   for   updating    {i.e.,    add   or    delete).  */ 

/is************************ ********* ** ************* ****** »******/ 

DCL  MENU_NUM  CHAR  (3)  , 

PIENtl_ENTRY  CHAR(fc9), 

SLCT_NUM  FIXED  (3)  ; 

/*    LOAD  DISPLAY  TABLE     */ 

DISPLAY_TBL   =    •    • ; 

PUT    STRING     (DISPLAY_TBL(1)  )     EDIT 

{•1)     RECORD    NAME:     • ,  REC_NAME)   (2  { A)  )  ; 
PUT    STRING     (DISPLAY_TBL  (2))     EDIT 

{'2)     RECORD    STORAGE   MODE:     ',REC    STRG    MODS)  (2  (A)  )  ; 
POT    STRING     (DISPLAY_TBL(3)  )     EDIT 

('3)      RECORD   LOCATION    MODE:     ', 
REC_LCTN_MODE)  {2(A)  )  ; 
IF    REC_LCTN_MODE    =    'CALC 
THEN    DO; 

COUNT    =    7; 

PUT    STRING     (DISPLAY_TBL  ("))     EDIT 

(•«)     RECORD    DUPLICATE    OPTION:      '  ,REC_DU?_OPTION)   (2(A)); 
PUT    STRING     (DISPLAY_TBL(5))     EDIT 

('5)     RECORD   CALC   KEY    OR    VIA    SET:     ', 
REC_CALC_VIA)  (2(A)); 
PUT    STRING     (DISPLAY_TBL  (fc))     EDIT 

('6)     ADD    DATA    ELEMENT    TO    •  ,REC_NAME)  (2  (A)  )  ; 
DISPLAY_TBL  (7)     =     'DELETE    DATA    ELEMENT    .     .     .'; 
END; 
ELSE    DO; 
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COUNT   =    6; 

POT    STRING     (DISPLAY_TBL  («))     EDIT 

{"»)     RECORD    CALC    KEY    OB    VIA    SET:     '  , 
REC_CALC_VIA)   (2(A)  )  ; 
PUT    STRING     (DISPLAY_TBL  (5))     EDIT 

(•5)     ADD    DATA    ELEMENT    TO    •  ,REC_NAME)  (2  (A)  )  ; 
END; 
OBTAIN    FIRST    SET     (POPULATED_WITH)  ; 
IF    ERROR_STATUS    -.=     '0307* 
THEN    DO; 

CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (GROUPED_IN)  ;       CALL    IDMS_3TATUS; 
END; 
DO    WHILE     (ERROR_STATUS    =    OK)  ; 
COUNT   =    COUNT    +    1 ; 
PUT    STRING    (DISPLAY_TBL  (COUNT)  )     EDIT 

(COUNT-lT')      ',LMNT_NAME)   (X  (2)  ,F(3)  ,2  (A)  )  ; 
OBTAIN    NEXT    SET     (POPULATED_WITH) ; 
IF    ERROR_STATUS    -.=    '0307' 
THEN    DO;~ 

CALL    IDPIS_STATUS; 

OBTAIN    OWNER    SET    (GEO  UPED_IN)  ;       CALL    IDMS    STATUS; 
END; 
END; 

DISPLAY_TBL  (COUNT*  1)     =     'X)     EXIT'; 
CALL    GEN_MENU     (MENU_  NUM,  PIENU_ENTRY, 

•**    CHANGE   OR    DELETE    RECORD    **  ■  ,  COUNT-  1  ,S1CT_B0B  ,2)  ; 
END    REC_CHG_MENU; 

CALC_VIA_CHG:  PROC     (MENU_ENTR  Y,R  EC_CALC_VIA)  ; 

/*  This  module  changes  the  value  of  an  existing  RE_CORD  */ 
/*  occurrence's  REC_CALC_VIA  field  based  on  the  value  of  */ 
/*     the   HENU_ENTRY.      This    module   assures   that   the   value  */ 

/*  assigned  to  REC_CALC_VIA  is  an  acceptable  value  based  */ 
/*      the    REC_LCTH_MODE    field.  */ 

/is*********************************************************/ 

DCL  HENU_NUM  CHAR  (3)  , 

HEHU_ENTRY  CHAR  (69)  , 

EEC_CALC_VIA  CHAF.(16), 

(CALC_SLCT_TBL(500)  ,  VI  A_SLCT_TBL  (500)  )     CHAP  (21)  , 
(SLCT_NUM/NUM_CALC/NUH_VIA)  FIXED     (3); 

/♦Load   VIA_SLCT_TBL    with    valid    VIA    Set    values    */ 

VIA_SLCT_TBL      =    '     ■ ; 

NUM_VIA   =   0; 

OBTAIN  FIRST  SET  (MEMEER_0F) ; 

DO    WHILE     (ERROR_STATUS    =    OK); 

NUM_VIA   =    NUM_VIA    ♦    1; 

IF    MENU_ENTRY    =    SET_NAf\E 

THEN    DO; 

PEC_LCTN_MODE    =     'VIA' ; 
REC~CALC_VIA    =    MEHU_ENTRY; 
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HETURN; 

END; 
ELSE  DO; 

PUT  STRING  (VIA_SLCT_TBL(NUM_VIA)  )  EDIT 

(NUM_VIA,')         ',SET_NAME,'    ~  ')  (F  (3)  ,  3  (A)  )  ; 

OBTAIN    NEXT   SET     (MEMBER_OF)  ; 

END; 
END; 

VIA_SLCT_TBL(NUM_VIA  +  1)     =     •       X)        EXIT'; 
IF    ERROR_STATUS    -.=     '0307'    THEN    CALL    IDMS_STATUS; 

/*      Load   CALC_SLCT_TBL    with    valid    CALC_KEY    values    */ 

CALC_SLCT_TBL      =     ■     *; 

NUM_CALC    =    0; 

OBTAIN    FIRST    SET     (POPUL  ATED_WITH)  ; 

IF    ERROR    STATUS    -.=     '0307' 

THEN    DO;~ 

CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (GROUPED_IN)  ;       CALL    IDMS_STATUS; 
END; 
DO    WHILE     (ERROR_STATUS    =    OK)  ; 
NUM_CALC    =    NU«_CALC    +     1; 
IF    MENU_ENTRY    =    LMNT_NAME 
THEN   DO; 

REC_LCTN_MODE    =     'CALC; 
REC_CALC_VIA    =    HENU_ENTRY; 
RETURN; 
END; 
ELSE   DO; 

PUT    STRING     (CALC_SLCT_TBL  (NUM_CALC)  )     EDIT 

(NUM_CALC,')         ',LMNT_NAME,'        •)   (F  (3)  ,  3  (A)  )  ; 
OBTAIN    NEXT    SET     (POPULATED_WITH)  ; 
IF    ERROR_STATUS    -•=     '0  307' 
THEN    DO;~ 

CALL    IDHS_STATUS; 

OBTAIN    OWNER    SET     (GROUPED    IN)  ;       CALL    IDMS_STATUS; 
END; 
END; 
END; 
CALC_SLCT_TBL  (NUH_CALC*1)     =    ■        X)        EXIT'; 

IF    REC_LCTN_HODE    =     •     ' 
THEN    DO; 

MSG    =     'HAKE    AN    ENTRY    IN    RECORD    LOCATION    BODE    FIRST'; 

CALL    MESSAGES; 

RETURN; 

END; 

IF  MENU_ENTRY   -=  •  • 
THEN  DO; 

PUT  STRING  (MSG)  EDIT  (MENU_ENTHY, 

•  IS  INVALID  CALC  KEY  OF  VIA  SET  -  USE  MENU') 
(A(16),A); 
CALL  MESSAGES; 
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END; 

/*      Display   valid   CALC_KEY   fields   if  any   */ 
IF    REC_LCTN_MODE    =    'CALC 
THEN    DO; 

IF    Mia    CALC    =    0 
THEN   DO; 

aSG=' RECORD    CONTAINS    NO    DATA    ELEMENTS    - 

NO    ACCEPTABLE    VALUE' ; 
CALL    MESSAGES; 
RETURN; 
END; 
DISPLAY_TBL    =    CALC_SLCT_TBL ; 
CALL    GEN_MENU    (MEN  U_NUM  ,MENU_EN  TR  Y, 

•**    SELECT    CALC    KEY    **', 
NUM_CALC,SLCT_NUM,3) ; 
IF    MENU    NOM    =    'X1 
THEN    DO? 

REC_CALC   VIA   =    '     •  ; 
RETURN; 
END; 
REC_CALC_VIA    =    SUBSTR (C ALC_SLCT_TBL (SLCT    NUM),7,16); 
END; 
ELSE    DO; 

/*      Dispaly    valid    VIA_SE   fields   if   any    */ 
IF    NUM_VIA   =    0 
THEN   DO; 

MSG='RECORD    IS    NOT    MEMBER    OF    ANY    SET    - 
HO    ACCEPTABLE    VALUE' ; 

CALL    MESSAGES; 

BETUBN; 

END; 
DISPLAY_TBL    =    VIA_SLCT_TBL; 
CALL    GEN_MENU    (MENU_NUM  ,MENU_EN  TR  Y, 

'**    SELECT    VIA   SET    **', 
NUM_VIA,SLCT_NUM,3) ; 
IF    MENU_NUM    =    'X' 
THEN    DOT 

REC_CALC_VIA   =    '     '  ; 

RETURN; 

END; 
REC_CALC_VIA    =    SUBSTR  ( VIA_SLCT_TBI  (SLCT_NUM)  ,7  ,  1  6)  ; 
END; 
END    CALC_VIA_CHG; 

REC_LMNT_CHG:       PROC     (SLCT_HUM,  MENU_ENTRY)  ; 

/*    This   module    links    existing    DATA_ELEMENT   occurrences    to      */ 
/*    an    existing    RE_CORD    occurrence.       If    the   MENU_SNTRY  */ 

/*  parameter   does   not    contain   a   valid   data    element   name  */ 

/*   then  a   complete  list   of   data   element    names    is   displayed   */ 
/*   for   the   user   to   select   from.  */ 

/**  ***************#*********#**********#**#**# *#*#*#** #**#**/ 
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DCL  MENU_NUM  CHAR  (3)  , 

MENU_ENTRY  CHAP.  (69)  , 

SLCT_NUM  FIXED  (3); 

IF     (SLCT_NUM    =    5    |      (SLCT_NUM    =65 

EEC    LCTN    MODE    ■     'CALC')) 
THEN    DO; 

IF    MENU    ENTEY   -■=     ■     ' 
THEN    DOT 

LMNT_NAME    =    MENU_ENTRY; 
SAVE_DB_NAME    =    DB_NAME; 
OBTAIN    CALC    RECORD     (DATA_ELEMENT)  ; 
DO   WHILE     (ERBOK_STATIJS   =~BEC_FOUH  D)  ; 

OBTAIN    OWNER    SET     (DEFINED_BY)  ;       CALL    IDMS    STATUS; 

IF    SAVE_DB_NAME   =    DB_NAME 

THEN 

ERROR_STATUS    =     'FWND'; 
ELSE 

OBTAIN    DUPLICATE    RECORD     (  DAT A_ ELEMENT )  ; 
END; 

IF     (EBROR_STATUS    -.=     '0326'     E    ERROB_STATUS    -.=     'FWND') 
THEN    CALL    IDMS_STATUS; 
IF    EBBOE_STATUS    =    'FWND' 
THEN    DO; 

STOBE    RECOED     (LHNT_REC)  ;       CALL    IDMS_STATUS; 
RETURN; 
END; 
ELSE    DO; 

PUT    STRING     (MSG)     EDIT 
(LHNT_NAME, 
•     DATA    ELEMENT    DOES    NOT    EXIST    -    USE    MENU')  (2(A)); 
CALL    MESSAGES; 
END; 
END; 

/*****       LIST    ALL    DATA    ELEMENTS    TO    SELECT    FROM    ******/ 

DISPLAY_TBL    =    '     •  ; 

OBTAIN    FIRST    SET     (DEFINED_BY) ; 

IF    EBROR_STATUS    =     '0307' 

THEN   DO; 

MSG    =    'NO    DATA    ELEMENTS    TO    CHOOSE    FROM!'; 

CALL    MESSAGES; 

RETURN; 

END; 
COUNT   =    0; 
DO    WHILE     (ERROR_STATUS    =    SEC_FOUND)  ; 

COUNT   =    COUNT    +1; 

PUT    STRING     (DISPLAY_TBL  (COUNT)  )     EDIT 

(COUNT,*)         ' ,LMNT_NAME, •        • )   (F  (3)  ,3  (A)  )  ; 

DOMAIN_TBL (COUNT)  =  LMNT_NAME; 

OBTAIN    NEXT    SET     (DEFI  NED_BY)  ; 
END; 
IF    EEEOR_STATUS    -•=     '0307' 
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THEN    CALL   IDHS_ST ATUS ; 

DISPLAY_TBL  (COUNT*  1)     =    '       X)        EXIT'; 

CALL    GEN_MENU     (MENU_NUM  ,MENU_EN  TRY, 

•**    ADD    DATA    ELEMENT    TO    A    RECORD    **■, 
COUNT,SLCT_NUM,3) ; 

IF    MENU_NUM    -.=    'X' 
THEN    DOT 

LMNT_NAME    =    DOM AIN_TBL (SLCT_N OK) ; 
FIND    CALC    RECORD    (DATA_ELEMENT)  ; 
STORE    RECORD     (LMNT_REC)  ;       CALL    IDMS_STATUS; 
END; 
END; 
ELSE    DO; 

LMNT_NAME    =    SDBSTR (DISPLAYJTBL ( SLCT_NUM+1 ) , 8 , 1 6) ; 
/**       FIND    CALC    RECORD     (LMNT_REC)  ;       CONFLICT    W/    SCHEMA==>    VIA    */ 
ERASE    RECORD    (I.MNT_REC)     PERMANENT;       CALL    IDMS_STATUS; 
END; 
END    REC_LMNT_CHG; 
END      CHG_DEL_REC; 

STRG_MODE_RTN:       PROC     (MENU_ENTRY, REC_STRG_KODE) ; 

/*************************************  ******  ************#* S******/ 

/*  This  module  updates  the  REC_STRG_MODE  field  in  the  RE_COED  */ 
/*  structure.  If  no  MENO_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data   base  designer   to  make   a   decision.  */ 

/♦♦♦♦♦♦A**************************************  **„#**:»*  ***********/ 

DCL  MENU_ENTBY  CHAR  (69), 

REC_STRG_MODE  CHAR  (2), 

THE_VALUE  CHAR  (Ifc)  , 

I  FIXED    DEC(2)  ; 

/*         LOAD    DISPLAY    TABLE    AND    DOMAIN   TABLE  */ 

';  DOMAIN_TBL(1)  =  'F'; 

•;  DOMAIN_TBL(2)  =  'V; 

•;  DOMAIN_TBL  (3)  =  'C  ; 
i  . 

/*      IF    NO    MENO_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY      */ 

THE_VALDE   =    REC_STRG_MODE; 
REC_STRG_MODE    =    MEN!J~EHTRY; 
IF    REC_STRG_MODE    =     •     ' 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLA Y_TBL, DO MAIN_TBL, THE    VALUE, 
' **    RECORD    STORAGE    MODES    **',3); 

REC_STRG_MODE   =    THE_VALUE; 

END; 
ELSE    DO; 
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DISPLAY_TBL(1) 

= 

•1) 

FIXED 

DISPLAY  TBL(2) 

= 

•2) 

VARAIBLE 

DISPLAY_TBL(3) 

= 

»3) 

COMPRESSED 

DISPLAYJTBL  (I») 

= 

■X) 

EXIT 

/*      THESE   WAS    A    MENU_ENTRY    —    RETURN    IF    VALID    MENU_ENTRY  */ 

DO   I    =    1    TO    3; 

IF    DOMAIN_TBL(I)     =    REC_STRG_MODE 

THEN 

RETURN; 
END; 

/♦THERE    MUST   HAVE    BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WRITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY*/ 

PUT    STRING     (MSG)     EDIT     ( REC_STRG_KODE, •    IS    NOT    ACCEPTABLE    ■, 

•FOR    RECORD    STORAGE    MODE    —    USE    MENU')         (3(A)); 
CALL    MESSAGES; 
CALL    SLCT_VALUE    (DISPLAY_TBL, DOMAIN_T3L,THE    VALUE, 

•**    RECORD    STORAGE    MODES    **  '  ,  3)  ; 
REC_STRG_MODE   =    THE_VALUE; 
END; 
END    STRG_MODE_RTN; 

LCTN_MODE_RTN:       PROC    (MENU_ENTnY,REC_LCTN_MODE)  ; 

/ft**************  **************************************  a******,*,,^ 

/*  This  module  updates  the  REC_LCTN_MODE  field  in  the  RE_CORD  */ 
/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data   base  designer   to  make   a   decision.  */ 

/**************************  ************************  txamsttzt^+f 

DCL  HENO_ENTRY  CHAR(69), 

REC_LCTN_MODE  CHAR (4)  , 

(THE_VALUE,SAVE_VALUE)  CHAR(U)  , 

I  FIXED    DEC  (2)  ; 

/*         LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE  */ 

DISPLAY_TBL(1)     =    '1)        CALC    KEY  •;       DOMAIN_TBL  {  1 )     =    'CALC"; 

DISPLAY_TBL(2)     =    •  2)        VIA    SET  ■  ;       DOMAINJTBL  (2)     =     'VIA'; 

DISPLAY_TBL(3)     -    'X)        EXIT  '; 

/*      IF    NO    MENU_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY       */ 

SAVE_VALUE   =    REC_LCTN_MODE; 
THE_VALUE    =       REC_LCTN_MODE; 
REC_LCTN_MODE    =    M£NU_ENTRY; 
IF    REC_LCTN_MODE    =    '     • 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLAY_TBL, DOMAIN_TBL,THE_ VALUE, 
'  **    RECORD    LOCATION    MODES    **',2); 

REC_LCTN_MODE   =    THE    VALUE; 

END; 
ELSE    DO; 

/*   THERE  WAS  A  MENU_ENTRY  —  RETURN  IF  VALID  MENU_ENTRY        */ 
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DO    I   =    1    TO    2; 

IF    DOMAIN_TBL  (I)    =    REC_LCTN_MODE 

THEN 

RETURN; 
END; 

/*    THERE    HOST    HAVE    BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WRITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY*/ 

PUT    STRING     (MSG)     EDIT    (REC_LCTN_MODE, ■     IS    NOT    ACCEPTABLE    ', 

'FOR    RECORD    LOCATION    MODE    — ~USE    MENU')         (3(A)); 
CALL    MESSAGES; 
CALL    SLCT_VALUE     (DISPLA Y_TBL, DOMAIN_TBL,THE_ VALUE, 

•**    RECORD    LOCATION    MODES    **',2); 
REC    LCTN_MODE   =    THE    VALUE; 
END; 

IF    SAVE_VALOE    -^    HEC_LCTN_i10DE 
THEN 

REC_CALC_VIA    =     •     '; 
END    LCTN_MODE_RTN; 

REC_DUP_RTN:       PROC    (MENU_ENT  EY  ,EEC_DUP_OPTION)  ; 

/*    This    module    updates    the   REC_DUP_OPTION  field    in    the    RE_CORD  */ 

/*   structure.      If   no   MENU_ENTRY   parameter  is   inputted   into   this  */ 

■/*   module,    a   list   of    possible    values    will  be   displayed   for   the  */ 

/*    data   base   designer   to   make   a   decision.  */ 

DCL  MENU_ENTRY  CHAR(fc9)  , 

REC_DUP_OPTION  CHAR  (2)  , 

THE_VALUE  CHAfi(lfc)  , 

I  FIXED    DEC  (2)  ; 

/*    LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE  */ 

DISPLAY_TBL{1)     =    *1)        DUPLICATES    FIRST  '; 

DOMAIN_TBL(1)  =  'DF'; 
DISPLAY_TBL(2)     =    '2)        DUPLICATES    LAST  '; 

DOMAIN_TBL  (2)  =  'DL'; 
DISPLAY_TBL(3)     =    '3)        DUPLICATES    NOT    ALLOWED'; 

DOMAIN  TBL(3)  =  '  DN  '  ; 
DISPLAY_TBL(tt)     =    'X)        EXIT  '; 

/*      IF    NO    HENU_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY       */ 

THE_VALDE   =    REC_DUP_OPTION ; 
REC_DUP_OPTION    =    MENU_ENTRY; 
IF    £EC_DUP_OPTION    =     '     ' 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLA Y_TBL, DO MAIN_TBL ,THE_VALUE, 

'**    RECORD    DUPLICATE    OPTIONS    **',3); 

REC_DUP_OPTION    =    THE_VALUE; 

END; 
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ELSE  DO; 
/*   THERE  BAS  A  MENU^ENTRY  —  RETURN  IF  VALID  HENU_ENTRY         */ 

DO  I  =  1  TO  3; 

IF  DOMAIN_TBL(I)  ■  REC_DUP_OPTION 

THEN 

RETURN; 
END; 

/*   THERE    MUST    HAVE   BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WRITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY*/ 

PUT    STRING     (MSG)     EDIT     ( REC_DUP_CPTION,  '    IS    MOT    ACCEPTABLE    ', 

•FOR    RECORD    DUPLICATE   OPTION    —    USE    MENU')         (3  (A)); 
CALL    MESSAGES; 

CALL    SLCT_VALUE     (DISPLA Y_TBL, DOMA IN_TBL ,THE_VALUE, 
•**    EECORD    DUPLICATE    OPTIONS    **',3); 
REC_DUP_OPTION    =    THE_VALUE; 
END; 
END    REC_DUP_RTN; 
END    RECORD    UPDATE; 
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DCL  MENU.ENTRY 

SLCT.NUM 
MF.NU.NHM 
(SET.OWNER.SET.MEMBER) 


CHAR(69)  , 
FIXED  DEC  (3)  , 
CHAR  (3)  , 
CHAR  (16)  ; 


IF    HENO_ENTRY    -■=    ■     • 
THEN    DO; 

SET.NAME   =    MENU.ENTRY; 

SAVE.DB.NAME    =    DB.NAME; 

OBTAIN    CALC    RECORD     (SE_T)  ; 

DO    WHILE    (ERROR_STATUS~=    REC.FOUND)  ; 

OBTAIN    OHNER    SET     (1INKED.BY) ;       CALL    IDMS.STATUS; 

IF   SAVE_DB_NAHE    =    DB.NAME 

THEN 

ERROR_STATUS    =    'FUND'; 

ELSE 

OBTAIN    DUPLICATE   RECORD     (SE    T)  ; 
END; 

IF    (ERROR.STATUS    -=    '0326'     S    ERROR.STATUS    -.=    'FUND') 
THEN    CALL    IDMS.STATUS; 
IF     (ERROR_STATUS    =     'FWND') 
THEN    DO; 

MENU.ENTRY    =    •     • ; 

CALL    CHG_DEL_SET     (MENU.ENTRY) ; 

RETURN; 
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END; 
ELSE   DO; 

DB_NAME    =    SAVE_DB_NAME; 

OBTAIN    CALC    RECORD     (DATA_BASE) ; 

POT    STRING     (HSG)     EDIT     (KEN  0_ENTRY, 

1    IS    NOT    AN    EXISTING    SET')      (A(1fc),A); 

CALL    MESSAGES; 

END; 
END; 

LOAD    TABLE    WITH    SET    NAMES  */ 

MENO_NOM    =     '     •; 

DO    WHILE    (MENU_NOM    -.=     'X')  ; 

DISPLAY_TBL    =    ■     •  ; 

PHT    STRING     (DISPLAY_TBL(1) )     EDIT     (M)       CREATE    SET1) 

(X{4)  ,A)  ; 
OBTAIN    FIRST    SET     (LINKED_BY)  ; 
IF    ERROR_STATrjS   -»=     '0307' 
THEN   CALL    IDMS_STATOS; 
COONT    =    1; 

DO'  WHILE     (ERROR_STATOS    =     REC_FO[JND)  ; 
COONT   =    COONT    +    1; 

POT    STRING     (DISPLAY_TBL  (COONT)  )     EDIT     (COONT,')         ', 
SET_NAME) 
(X  12)  ,  F  (3),  2(A)  ); 
DB_KEY_TBL  (COONT)     =    DBKEY; 
OBTAIN    NEXT    SET     (LINKED_BY) ; 
IF    ERROR_STAT0S    -.=     *0307' 
THEN    CALL    IDBS_STAT0S; 
END; 

POT    STRING     (DISPLAY_TBL(COONT    +     1))     EDIT     ('  X)       EXIT') 

(A)  i 

/*  DISPLAY    MENO         /       ACCEPT    EDIT    REPLY         */ 

CALL'GEN_MENU     (MENU_NOM,  MEHO_ENTR  Y, '        **    SET    OPDATE    **•-, 
COONT,SLCT_NOM,3)  ; 

IF    MENO_NOM    =    'X' 
THEN 

RETORN; 

IF   SLCT_NOM    =    1 
THEN 

CALL    NEW_SET     (MENO_ENTRY ) ; 
ELSE    DO; 

OBTAIN    RECORD     (SE_T)     DBKEY     (DB_KEY    TBI,  (SLCT    NOM)  )  ; 

CALL    IDP!S_STATOS; 

CALL    CHG_DEL_SET     (MENO_ENT3Y)  ; 

END; 


END; 
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NEW_SET:       PROC     (HENU_SNTRY)  ; 
/***************************************************************/ 

/*  This  module  established  a  new  SET  occurrence  by  defaulting  */ 
/*  the  SET  occurrence  fields  and  callinq  the  modules  to  update  */ 
/*   the    fields   based    on    the   data   base    designer's    MENU_ENTRY.  */ 

/*  Once   updating    is   complete,   the   new  SET   occurrence  is   stored.*/ 

/******♦***************«*********************#******************/ 

DCL  STATUS  CHAR  (4) , 

MENU_NUM  CHAR  (3), 

MENIJ~ENTRY  CHAR  (69)  ; 

/*       INITIALIZE    AND    DEFAULT    SET    FIELDS  */ 


SE_T 

= 

■  •  • 

» 

SET  OWNER 

= 

i  i  . 

SET  MEMBER 

= 

i  t  • 

SET_LINK 

= 

1  N  PO  ■  ; 

SET_MEM 

= 

•MA'  ; 

SET  ORDER 

= 

'FIRST*  ; 

set!sort_lmnt 

= 

■  1  • 

SET_DUP_OPTION 

= 

1  DN'  ; 

SET  VALUE 

= 

'  1M'  ; 

SET_INVRS_VAL 

= 

•  11'  ; 

/*      HAS    A    SET    NAME    BEEN    PROVIDED    FROM    SECONDARY    MENU?  */ 

IF    MENU_ENTRY    =    '     • 
THEN 

CALL    SET_UP_M£NH     (MENU_  NUM.  MENU_ENTRY, 

'**    CREATE    NEW    SET    **') ; 
ELSE 

MENIJ_NUM    =    ' V ; 

/*       ALLOW    ADDITION   OF    SET    ATTRIBUTES    UNTIL    EXIT  */ 

DO    WHILE     (MENU_NOM    -.=    'X<); 
IF    MENU_NUM    =    ' V     THEN 

CALL    NEW_SET_NAME    (MENU_ENTRY  ,S  ET_NAME)  ; 
ELSE    IF    MENU_NUM    =    '2«     THEN 

CALL    MEM_OWN_RTN     (MENU_ENTRY, SET_OWNER, SET_MEHBEB , 
•**    SELECT    SET~OWNER    **•  )  ; 
ELSE   IF    HENU_N'JM    =    '3'     THEN 

CALL    MEM_OWN_RTN     (MEN U_ENTRY, SET_MEMBER , SET_OWNER , 
•**    SELECT    SET    MEMBER    **')  ; 
ELSE    IF    MENU_NUfl    ■    '4'     THEN 

CALL    SET_VALUE_RTN     (  MENU_ENTR Y,  SET_VALUE)  ; 
ELSE    IF    MENU_NUM    =    '5'    THEN 

CALL    SET_VALUE_RTN     (M  EN  U_ENTR  Y,SET_IN  VES_VAL)  ; 
ELSE    IF    MENU_NUM    =    'fc'     THEN 

CALL    LINK_RTN     (MENU_ENTFY  ,  SET_LINK  )  ; 
ELSE    IF    MENU_NUM    =    '7*     THEN 

CALL    MEM_RTN     (MENU_ENTRY,  SET_  MEM)  ; 
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ELSE    IF    MENU_NHM    =    '8'     THEM 

CALL    ORDER_RTN     (MENU_ENTR  Y,  SET_OHDER)  ; 
ELSE    IF    NENU_NUM    =    '9'~THEN 

CALL    SORT_LMNT    RTN     (H  BBO    BUTE  Y,  SET_SORT_LMNT)  : 
ELSE    IF    MENU_NUM    =    '10'    THEN 

CALL    DUP_OPTIOM_RTN     (  MENU_ENT  RY  ,  SET_DUP_OPTION)  ; 
CALL   SET_UP_MENU     (  MENTJ_NUM,  MENU_ENTR  Y, 

■**    CREATE    NEW    SET    ** • ) ; 
END; 

IF    SET_NAME    =    •     ' 
THEN    DO; 

HSG    =    'SET    NAME    IS    BLANK    —    NO    ADD    MADE'; 
CALL    MESSAGES; 
RETURN; 
END; 
STORE    RECORD    (SE_T)  ;  CALL    IDMS_STATUS; 

/*****      CONNECT    SET_OHNEE    TO    RESPECTIVE    RECORD    **************/ 

IF  SET_OWNER  -^=  '  ' 
THEN  DO; 

REC_NAME    =    SET_OWNER; 

SAVE_DB_NAME   =~DB_NAME; 

OBTAIN    CALC    RECORD    (RE_CORD)  ;       CALL    IDMS_ST&TUS; 

OBTAIN    OWNER    SET     ( DIVIDED_INTO)  ;       CALL    IDMS    STATUS; 

DO    WHILE     (SAVE_DB_NAME    -.=    DB_NAME); 

OBTAIN    DUPLICATE    RECORD    (RE_CORD) ;       CALL    IDMS_STATUS; 
OBTAIN    OWNER    SET     (DIVIDED_INTO)  ;       CALL    IDMS_STATUS; 

END; 

CONNECT  RECORD  (SE_T)   SET  (OWNER_OF)  ;   CALL  IDMS_STATUS; 

END; 

/*****      CONNECT   SET_MEMBER    TO    RESPECTIVE    RECORD    *************/ 

IF    SET_MEMBER    -*=    •     > 
THEN    DO; 

REC_NAME    =    SET_MEMBER; 

SAVE_3B_NAME    =    DB_NAME; 

OBTAIN    CALC    RECORD    (RE_CORD)  ;       CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     ( DIVIDED_INTO) ;       CALL    IDMS    STATUS; 

DO    WHILE     (SAVE_DB_NAME    -=    DB_NAME); 

OBTAIN    DUPLICATE    RECORD    (RE_CORD) ;       CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (DIVIDED_IHTO)  ;       CALL    IDMS_STATUS; 
END; 

CONNECT    RECORD     (SE_T)        SE^    (MEMBER    OF);       CALL    IDMS    STATUS; 
END; 

NSW_SET_NAME:       PROC     (M  ENU_ENTRY,  SET_HAME)  ; 

/*   This   module   allows   the   data  base   desiqner   to  assiqn  a    set  */ 

/*   name   to  a   newly  created   SET   occurrence.      Before  the   set  */ 

/*   name   is   accepted,   a    check   is   made    to    verify   that   it   does  */ 

/*   not    already   exist.  */ 
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DCL  MENU_ENTRY  CHAR  (69), 

(SET_NAME,SAVE_NA.ME)  CHAB(16), 

STATUS  CUAR(«)  ; 

SET_NAME    =    MENU_ENTBY; 

CALL    EDIT_NAME     (SET_N AHE, STATUS)  ; 

IF    STATUS    =     'GOOD' 

THEN    DO; 

SAVE_NAME    =    SET    NAME; 

SAVE_DB_NAME    =    DB_NAME; 

OBTAIN    CALC    RECORD     (SE_T)  ; 

DO    WHILE     (EBBOR_STATUS~=    REC_FOUND)  ; 

OBTAIN    OWNER    SET     (LINKED_BY);        CALL    IDHS_STATUS; 

IF   SAVE_DB_NAaE    =    DB_NAME 

THEN 

EBROR_STATHS    =    •  FWND*; 
ELSE 

OBTAIN    DUPLICATE    RECORD     (SE_T)  : 
END; 

IF     {ERROR_STATOS    -=    '0326'    S    ERBOB_STATOS    1=     'FWND') 
THEN    CALL    I DHS_ST ATUS ; 

IF    ERROB_STATUS    =     'FWND' 
THEN    DO; 

PUT    STRING     (MSG)     EDIT     (SET_NAHE,'     ALREADY    EXISTS"  )  (2  ( A)  )  ; 

CALL    MESSAGES; 

SET_NAME   =    '     < ; 

END; 
ELSE   DO; 

DB_NAME    ■    SAVE_DB_NAME; 

OBTAIN    CALC    RECORD     (DATA_BASE); 

END; 
END; 
ELSE 

SET_NAME    =     '     »  ; 
END    NEW_SET_NAME; 
END    NEW_SET; 

CHG_DEL_SET:       PROC     (MENU_ENTRY)  ; 
/********************************#***************************»**/ 

/*    This    module   changes   and   deletes   SET    fields   of   the    "current"   */ 
/*   SET    occurrence.  */ 

/***********************************************#***************/ 

DCL  DEL_SW  CHAR(  1)  , 

(SAVE_NAME,SAVE_OWNER,SAVE_MEMBER)  CHAR(16), 

MENU_NUPI  CHAR  (3)  , 

MENU_ENTRY  CHAR(69)  ; 


SA7E_0WNER,    SAVE_MEMBER    =     ' 
IF    MENU_ENTRY    =     'DELETE' 
THEN    DO; 
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POT    STRING     (MSG)     EDIT     (SET_NAME,'     SET    DELETED' )   (2  (A)  )  ; 

OBTAIN    CURRENT    RECORD    (SE_T) ; 

ERASE    RECORD     (SE_T)  ; 

CALL    IDMS_STATUS; 

CALL  MESSAGES; 

RETURN ; 

END; 


/*  OBTAIN    VALUES    FOR    SET_OWNER    5    SET_MEMBER    IF    EXISTENT         */ 

OBTAIN    CURRENT    RECORD    (SE_T)  ; 
IF    SET     (OWNER_OF)     MEMBER 
THEN    DO; 

OBTAIN    OWNER    SET     (OWNER_OF)  ;       CALL    TDMS_STATUS; 

SAVE_OWNER/SET_OWNER   =    REC_NAME; 

END; 
ELSE 

SET_OHNER   =     ■     '  ; 

OBTAIN    CURRENT    RECORD    (SE_T)  ; 
IF    SET    (MEMBER_OF)     MEMBER 
THEN    DO; 

OBTAIN    OWNER    SET     (MEMBER_OF)  ;        CALL    IDMS_STATUS; 

SAVE_HEMBEH,SET_MEM3ER    =    EEC_NAME; 

END; 
ELSE 

SET_MEMBER   =     '     • ; 

/*       MAKE    CHANGES    TO    SET    INFO    UNTIL    EXIT  */ 

SAVE_NAME   =    SET_NAME; 

CALL    SET_UP_MENU     (MENU_NUM, MEN U_ENTRY , 

'**    CHANGE    OR    DELETE    SET    **'  )  ; 

DO    WHILE     (HENU_NUB    -.=    'X'); 
IF    MENU_NUM    =    • 1'     THEN 
DO; 

CALL    CHG_SET_NAME    (M ENU_ENTRY ,SET_NAME) ; 
IF    SET_NAME   -.=     •     ' 
THEN 

SAVE_NAME   =    SET_NAME; 
END; 
ELSE    IF    HENU_NUM    =    '2'     THEN 

CALL    MEM_OWN_RTN     (MEN U_ENTR Y, SET_OWNER, SET_KEMBER , 
'**    SELECT    SET    OWNER    **'); 
ELSE   IF    MENU_NUM    =    "3'     THEN 

CALL    MEM_OWN_RTN     ( MENU_ENTRY,SET_MEMBER,SET_OKNER , 
'**    SELECT    SET~MEMBER    **')"; 
ELSE    IF    MENU_NUM    =    '4'     THEN 

CALL    SET_VALUE_RTN     (MENU    ENTRY,  SET_VALUE)  ; 
ELSE    IF    MEHU_NUM    =    '5'     THEN 

CALL    SET_VALUE_RTN     (MENU_ENTR  Y,  SET_IN  VRS_  VAL)  ; 
ELSE    IF    MENU_NUM    =     't'    THEN 
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CALL    LINK_RTN     ( MENU_ENTEY,SET_LINK) ; 
ELSE    IF    MENU_NUM    =    '7'     THEN 

CALL    MEM_ETN     (MENU_ENTEY,  SET_  MEM)  ; 
ELSE   IF    MEN0_NUM    =     '8'    THEN 

CALL    OBDEB_BTN     (MENU_EKTR  Y,  SET_OHDEH)  ; 
ELSE    IF    MENU_NUM    =    '9'     THEN 

CALL    SOBT_LMNT_BTN     (MENl!_ENTRY,SET_SORT_LMNT)  ; 
ELSE    IF   MENU_NUM~=    MO'     THEN 

CALL    DUP_OPTION_RTN     ( MENU_ENT  RY,SFT_DUP_OPTION)  ; 
CALL    SET_UP_MENU     (MENU_NUM,  MENU_ENTRY, 

•**  CEEATE  NEW  SET  **•); 
END; 

/*       IF    BLANK    SET_NAHE    THE    CONFIBM    DELETION    AND    EITHEP    DELETE    OR 
ABORT    DELETE    REQUEST.  */ 

IF    SET_NAME    =     •     ' 
THEN    DO; 

CALL    CLHSCE; 

CALL    BLANK_LINE(5)  ; 

DISPLAY     ('CONFIBM    DELETE    BY    TYPING    "D"*): 

CALL    BLANK_LINE(5) ; 

DISPLAY  ('====>')  REPLY  (DEL_SW); 

IF  DEL_SW  =  'D' 

THEN  DO; 

PUT    STEING    (MSG)     EDIT     (SAVE_NAME,'    SET    DELETED')      (2(A)); 

FIND    CURRENT    BECORD     (SE_T)  ;~ 

EEASE    BECORD     (SE_T)  ; 

CALL    IDMS_STATUS; 

CALL    MESSAGES; 

RETURN; 

END; 
ELSE    DO; 

MSG    =    'DELETE    REQUEST    ABORTED'; 

CALL    MESSAGES; 

SET_NAME    =    SAVE_NAME; 

END; 
END; 

IF  SAVE_OHNER  -.=  SET_OWNER 
THEN  DO; 

/********    DELETE    PREVIOUS    SET_OWNER    **************/ 
IF    SAVE_OWNER    -.=     •     ' 
THEN    DO; 

SAVE_DB_NAME    =    DB_NAME; 

REC_NA«E   =    SAVE_OWNER; 

OBTAIN    CALC    BECOED     (RE_CORD)  ;       CALL    IDMS_STATUS; 

OBTAIN    OWNEE    SET     (DIVIDED_INTO) ;        CALL    IDMS_STATUS; 

DO    HHILE     (SAVE_DB_NAME   -.=    DB_NA[1E)  ; 

OBTAIN    DUPLICATE    RECORD     (RE_CORD)  ;       CALL    IDMS_STATUS; 
OBTAIN    OWNEB    SET     (DIVIDED_ItlTO)  ;       CALL    IDMS_STATUS; 
END; 

DISCONNECT    RECORD     (SE_T)       SET     (OKNER_OF); 
END; 

-    157    - 


/************    ADD    NEB    SET_OWNER    ********************♦/ 
IF    SET_OWNER    -.=    '      ' 
THEN    DO; 

R3C_NAME    =    SET_OWNER; 

OBTAIN    CALC    RECORD     (RE_CORD);       CALL    IDMS_STATUS ; 

OBTAIN    OWNER    SET     (DIV IDED_INTO) ;       CALL    IDMS    STATUS; 

DO    WHILE     (SAVE_DB_NAME   -■■     DB_NAME)  ; 

OBTAIN    DUPLICATE    RECORD     (RE_CORD)  ;       CALL    IDMS_STATUS; 
OBTAIN    OWNER    SET    { DIVIDED_INTO) ;       CALL    IDHS_STATUS: 

END; 

CONNECT    RECORD     (S2_T)     SET     (OWNER_OF)  ; 

END; 

END; 

IF    SAVE_MEMBER    -.=    SET.MEMBER 
THEN    DO; 

/****    DELETES    PREVIOUS    SET    MEMBER       ******************/ 
IF    SAVE_MEMBER    ->=     •     • 
THEN    DO; 

SAVE_DB_NAME    =    DB_NAME; 

REC_NAME    =    SAVE_HEMBER; 

OBTAIN    CALC   RECORD     (RE_CORD)  ;        CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (DIV IDED_INTO) ;       CALL    IDMS_STATUS; 

DO    WHILE     (SAVE_DB_NAME    -m    DB_NAME)  ; 

OBTAIN    DUPLICATE    RECORD     (RE_CORD)  ;       CALL    IDMS_STATUS; 
OBTAIN    OWNER    SET     (DIVIDED    INTO) ;       CALL    IDMS_STATUS; 
END; 

DISCONNECT    RECORD     (SE_T)        SET     (MEMBER_OF)  ; 
END; 
/*************    END    *************************#******/ 

/*********    ADD    NEW    SET    MEMBER    ***********************/ 
IF    SET_MEMBER   -.=     '     • 
THEN    DO; 

REC_NAME    ■    SET_MEMBER; 

OBTAIN    CALC    RECORD     (EE_CORD);        CALL    IDMS_STATUS; 

OBTAIN    OWNER    SET     (DIVIDED    INTO) ;       CALL    IDMS    STATUS; 

DO    WHILE     (SAVE_DB_NAME    -.=  ~DB_NAME)  ; 

OBTAIN    DUPLICATE    RECORD     (RE_CORD)  ;       CALL    IDMS_STATUS; 
OBTAIN    OWNER    SET     { DIVIDED_IHTO)  ;       CALL    IDMS    STATUS; 

END; 

CONNECT    RECORD     (SE_T)     SET     (MEMBER_OF)  ; 

END; 

/#******«*******    EHD    *******«*******#***************/ 
END; 

FIND    CURRENT    RECORD     (SE_T)  ;       CALL    IDMS_STATUS; 
MODIFY    RECORD     (SE_T) ;       CALL    IDMS_STATUS; 
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CHG_SET_NAME:       PHOC     (MEHU_EU  TE  Y,SET_NA  ME)  ; 
/#*********#**#************************************#************/ 

/*      This    module   changes   the    set   name    of   the    "current"    SET  */ 

/*      occurrence   based   on   the    MENU_ENTRY.  */ 

DCL  MENO_ENTRY  CHAR(f.9)  , 

SET_NAME  CHAR  (16), 

STATUS  CHAR  (4)  ; 

SET_NAME    =    MENU_ENTRY; 
CALL    EDIT_NAME    (SET_NAME,  STATUS)  ; 
IF    STATUS    =     'GOOD' 
THEN    DO; 

.     IF    SAVE_NAME   =    SET_NAME 
THEN 

ENTER_KEY    =    •     •;  /*       NULL    STATEMENT       */ 

ELSE    DO; 

SAVE_DB_NAME    =    DB_NAME; 

OBTAIN    CALC    RECORD     (SE_T)  ; 

DO    WHILE     (ERSOR_STATUS~=    REC_?OUND)  ; 

OBTAIN    OWNER    SET     (LINKED_BY);       CALL    IDMS_STATUS: 

IF    SAVE_DB_NAME    =    DB_NAME 

THEN 

EEROR_STATUS  =  'FWND'; 
ELSE 

OBTAIN    DUPLICATE    RECORD     (SE_T)  ; 
END; 

IF     (ERROR_STATUS    -.=    '0326'     £    ERROR_STATUS    -.=     'FWND') 
THEN    CALL    IDMS_STATUS; 
IF     (ERPOR_STATUS    =     'FWND') 
THEN    DO; 

PUT   STRING     (MSG)     EDIT    (SET_NAME,'     ALREADY    EXISTS') 

12(h)); 

CALL    MESSAGES; 
SET_NAHE    =    SAVE_NAME; 
END; 
ELSE    DO; 

DB_NAHE    =    SAVE_DB_NAME; 

OBTAIN    CALC    RECORD     (DATA_BASE)  ; 

IF    SET    NAME    -.=     ■     • 

THEN 

SAVE_NAME    =    SET_NABE;    /*IN    CASE    ABORT    A    DELETE    WE    WANT 
END;  /*TO    KNOW    THE    LAST    GOOD    S£T_NAME*/ 

END; 
END; 
ELSE 

SET_NAME   =    SAVE_NAME; 
END    CHG_SET_NAME; 
END   CHG    DEL    SET; 
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SET_UP_MENU:       PEOC    (MENU_NUK,MENU_ENTRY,MENU_MSG) ; 

/*   This   module   displays   the   SET  fields   that   can   be  updated   for      */ 
/*  SET   occurrences.  */ 

DCL  MENU_MSG  CHAE  (30)  , 

MENU_NUM  CHAR  (3), 

MENU_ENTRY  CHAE  (69)  , 

STATUS  CHAR  («)  , 

SECT  CHAR  (72), 

(SLCT_N[JH,NUN_ATTRIBIJTES)  FIXED    DEC  (3)  ; 

STATUS  =    "BAD' ; 
DO    WHILE     (STATUS    =     'BAD'): 
HSG    =    MENU_MSG; 
CALL    MENU_HEAD; 
PUT    STRING     (EDIT_OUT)     EDIT 

(•     1)        SET    NAME:        ',    SET_NAME)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(■    2)        SET    OWNEE:        ',    SET_OWNER)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

{•    3)        SET    MEMBER:        ',    S2T_MEMBER)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(■    4)       SET    VALUE:        ',    SET_VALUE)      (2(A)); 
DISPLAY     (EDIT_OUT); 
PUT    STRING     (EDIT_OUT)     EDIT 

('     5)        SET    INVERSE    VALUE:        ',    SET_INVRS    VAL)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(•    fc)       SET    LINKAGE:        ',    SET_LINK)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(•     7)        SET    MEMBERSHIP:       ',    SET_MEM)      (2(A)); 
DISPLAY     (EDIT.OUT) ; 
PUT    STRING     (EDIT_OUT)     EDIT 

('    8)       SET    ORDER:        ',    SET_ORDER)      (2(A)); 
DISPLAY     (EDIT_OUT) ; 

IF     (SET_OEDER    =    ' ASC •     |     SET_ORDER    =     'DES') 
THEN   DO; 

NUM_ATTRIBUTES    =    10; 
PUT~STRING    (EDIT_OUT)     EDIT 

('    9)        SET    SORT    ELEMENT:        ',    SET_SORT    LMNT)      (2(A)); 
DISPLAY     (EDIT_OUT)  ; 
PUT    STRING     (EDIT_OUT)     EDIT 

(MO)        SET    DUPLICATE    OPTION:       ',    SET_DUP_OPTION)      (2(A)); 
DISPLAY    (EDIT_OUT)  ; 

END; 
ELSE 

NUM_ATTIUBUTES    =    8  ; 
DISPLAY     (■    X)        EXIT1); 
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CALL    BLANK_LINE  (2)  ; 
DISPLAY    ('====>■)     REPLY     (SLCT)  ; 

CALL    EXAMINE_ENTRY     (SLCT, MENU_NOM , H ENU_ENTRY,SLCT_NUM , 
STATUS, NUM_ATTRIBUTES)  ; 
END; 
END    SET_UP_HENU; 

MEM_OWN_RTN:       PBOC    (MENU_ENTEY ,CHG_E EC, TEST_EEC,MENU_MSG) ; 

/**  ************* ******************************************** *****/ 

/*  This   module   verifies   that    the   CHG_REC    parameter   exists  as  */ 

/*   an   occurrence    of   the    RE_COED  structure  of   the   user's    data  */ 

/*    base  and  that    it   is   different   than   TEST_EEC.      This   is  */ 

/*   done   to   avoid   havinq   identical   owner  and   member    records   for      */ 
/*   the   same  SET   occurrence.  '  */ 

/************************#***#*************#*********************/ 

/*      THIS    ROUTINE    VERIFIES    THAT   THE    CHOSEN    RECORD    EXISTS    AND    THAT 

IT    IS    DIFFEEENT    THAN    THE    OTHER    EECORD    OF    THAT    SET  V 


DCL  MENU_NUM  CHAR  (3), 

MENU_ENTEY  CHAR  (69)  , 

(CHG_REC,TEST_REC)  CHAR(16), 

(SOB,TBL_SIZE)  FIXED    DEC(3), 

MENU_HSG  CHAR(KO)  ; 

/*      LOAD    DISPLAY_TBL    AND    DOMAIN_TBL    WITH    EXISTING    RECOPDS  */ 

DISPLAY_TBL    =    •     • ; 

OBTAIN    FIRST    SET    ( DI VIDED_INTO)  ; 

IF  EEROR_STATUS  =  '0307' 

THEN  DO;~ 

PUT  STRING  (MSG)  EDIT  ('NO  EECOEDS  TO  SELECT  FROM!')  (A); 

CALL  MESSAGES; 

RETUEN; 

END; 
TBL_SIZE  =  0; 
DO  WHILE  (EEROR_STATUS  =  OK)  ; 

TBL_SIZE  =  TBL_SIZE  +  1; 

PUT  STRING  (DISPLAY_TBL(TBL_SIZE))  EDIT 

(TBL_SIZE,  •)    '  ,REC_NAHE)  (X  (2)  ,  F  (3)  ,  2  (A)  )  ; 

DOMAIH_TBL(TBL_SIZE)    =    REC_NAME; 

OBTAIN    NEXT    SET     (DIVIDED_INTO)  ; 
END; 

IF    ERROB_STATUS    -■=    '0307' 
THEN    CALL    IDMS_STATUS; 
DISPLAY_TBL(TBL_SIZE+1)     =     ■  X)        EXIT*; 

/*      IF    NO    SELECTION    THEN    GIVE    LIST    OF    RECORDS  */ 

IF    MENU_ENTRY    =    ■     ' 
THEN    DO; 

CALL    GEN_MENU     (MENU_NUM  ,  HENII    ENTRY, MENU    MSG,  TBL_SIZE  , 
SLCT_NUM,3) ; 
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IF  MENU  NUM  =  '  X« 
THEN  DO? 

CHG_REC    =     '     •; 
RETURN; 
END; 
DO    WHILE     (DOMAIN_TBL(SLCT_NUM)     =    TEST_REC)  ; 

MSG   =     'THE    SAME    RECORD    CANNOT    BE    BOTH    MEMBER    S    OWNER"; 

CALL    MESSAGES; 

CALL    GEN_MEND     (MENU_NUM,MEN  U_ENTR  Y  ,  MENU_MSG  , 

TBL_SIZE,SLCT_NUM,3)  ; 
IP    MENU_NUM    =     'X' 
THEN    DO; 

CHG_REC    =    '     • ; 
RETURN; 
END; 
END; 

CHG_REC    =    DOMAIN_TBL(SLCT_NUM)  ; 
RETURN; 
END; 

/*       A    MEMBER/OWNER    RECORD    WAS    GIVEN    —    VERIFY  */ 

CHG_REC    =    HENU_ENTRY; 

DO    SUB   =     1    TO    TBL_SIZE      WHILE     (CHG_REC    -.=    TEST    EEC)  ; 

IF    CHG_REC    =    DOMAIN_TBL(SUB) 

THEN 

RETURN;  /*    GOOD    SELECTION    —    RETURN    */ 

END; 

/*       A    NON    ACCEPTABLE    RECORD    WAS   GIVEN    —    DISPLAY    ERROR    AND    GIVE    */ 
/*      A    LIST    OF    VALID    RECORDS    TO    CHOSE    FROM.  */ 

IF    CHG_REC   =    TEST_REC 
THEN    DO; 

MSG    =    'THE    SAME    RECORD    CANNOT    BE    BOTH    MEMBER    C    OWNER'; 

CALL    MESSAGES; 

END; 
ELSE    DO; 

PUT    STRING     (MSG)     EDIT 

(CHG_REC,'     NOT    AN    EXISTING    RECORD    —    USE    MENU*) 
(2(A))  ; 

CALL    MESSAGES; 

END; 

CALL    GEN_MENU     (MENU_NUM ,MENU_2NTRY , MENU_MSG, TBL_SIZE, 

SLCT_NUM,3) ; 
IF  MENU_NUM  =  'X' 
THEN  DO; 

CHG_HEC   =     '     • ; 

RETURN; 

END; 

DO    WHILE     (DOMAIN_TBL  (SLCT_NUM)     =    TEST_REC); 

MSG    =    'THE    SAME    RECORD    CANNOT    BE    BOTH    MEMBER    £    OWNER'; 
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CALL  MESSAGES; 

CALL  GEN_MENU  (HEN U_NUM , MENU_ENTRY , MENU  MSG.TBL  SIZE, 

SLCT_NUM,3) ; 
IF  MENU_HUM  =  'X' 
THEN  DOT 

CHG_REC    =    •     •  ; 
RETURN; 
END; 
END; 

CHG_REC   =    DOMAIN_TBL  (SLCT_NUM)  ; 
END    MiM_OWN_HTN; 

LINK_RTN:       PROC     (MENU_ENTRY, SET_LINK) ; 
/*******************»**************»*******************#******#**/ 

/*    This   module   updates    the    SET_LINK    field  in   the    SET  */ 

/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data    base  designer   to  make   a   decision.  */ 

/is**************************************************************/ 


DCL 


MENU_ENTRY 
SET_LINK 
THE    VALUE 


CHAK  (6^  , 
CHAR  (3)  , 
CHAE(lfc) , 

FIXED    DEC  (2) 


/* 


LOAD    DISPLAY    TABLE    AND    DOMAIN   TABLE 


*/ 


displayjtbl(i) 
display!tbl(2) 
display_tbl(3) 
display_tbl{4) 
display_tbl(5) 


= 

•1) 

NEXT 

DOMAIN_TBL(  1) 

= 

•2) 

NEXT 

PRIOR 

DOMAIN    TBL(2) 

= 

•3) 

NEXT 

OWNER 

DOMAIN  JTBL  (3) 

= 

"*) 

NEXT 

PRIOR 

OWNER' 

DOHAItl_TBL(U) 

= 

•X) 

EXIT 

IJ,     I 

»HB    • 
■NO    • 

'  NPO' 


/*      IF    NO    MENO_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY 

THE_VAL0"E  =    SET_LINK; 
SET~LINK    =    MENU_ENTRY; 
IF    SET_LINK    =    '     ' 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLA Y_TBL, DO MAIN_TBL ,THE_VALUE, 
'**    SET    LINKAGE    VALUES    **',«); 

SET_LINK    =    THE_VALUE; 

END; 
ELSE    DO; 


THEHE    WAS    A    MENU    ENTRY    —    RETURN    IF    VALID    MENU_SNTRY 


*/ 


DO    I   =    1    TO    4; 

IF    DOMAIN_TBL  (I)    =    SET_LINK 

THEN 

RETURN; 
END; 


/*  THERE  MUST  HAVE  BEEN  AN  INVALID  ENTRY  TO  GET  TO  THIS  POINT. 
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WPITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY    */ 

POT    STRING     (MSG)     EDIT     (SET_LINK,'    IS    NOT    AN    ACCEPTABLE    ', 

•VALUE    FOR    SET    LINKAGE    —    USE    MENU')        (3(A))  ; 
CALL    MESSAGES; 
CALL    SLCT_ VALUE     (DI3PLA Y_TBL, DOMAINJTBL.T HE_VALUE, 

'**    SET   LINKAGE    VALUES    **',4); 
SET_LINK    =    THE_VALUE; 
END; 
END    LINK_RTN; 

SET_VALUE_RTN:       PROC     (  MENII_ENTRY,SET_VALUE)  ; 

/*****  *************************<,********  ********************  *****/ 

/*    This   module    updates    the    SET_VALUE   field   in   the   SET  */ 

/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*    data   base  designer   to  make  a   decision.  */ 

/***************************************** *******************#»**/ 


DCL 


menu_entry 

set_value 

theIvalue 

I 


CHAR  (69)  , 
CUAR(2)  , 
CHAR{16)  , 

FIXED    DEC  (2) 


/*         LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE 


DISPLAI_TBL(1)     = 

*1) 

1    TO    1 

DISPLAY_TBL(2)     = 

•2) 

1    TO    MANY 

DISPLAY~TBL(3)    = 

•X) 

EXIT 

DOMAIN_TBL(  1)     *     Ml' 
DOMAIN_TBL(2)     =    MM' 


/*      IF    NO    MENU_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY       */ 

THE_VALUE   =    SET_VALUE; 
SET_VALUE    =    MEHU_ENTRY; 
IF    SET_VALUE   =    ■     * 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLA Y_TBL , DOHAIU_TBL ,THE_VALU2 , 
i**    SET    VALUE    OPTIONS    **',2); 

SET_VALUE    ■    THE_VALUE; 

END; 
ELSE    DO; 


/*      THERE    WAS    A    MENU_ENTRY    —    RETURN    IF    VALID    MENU    ENTRY 


*/ 


DO   I   =    1    TO    2; 

IF    DOMAIN_TBL(I)    =    SET_VALUE 

THEN 

RETURN; 
END; 


/*      THERE    MUST    HAVE    BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WPITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY*/ 

PUT    STRING     (MSG)      EDIT     (SET_VALUE,"    IS    NOT    AN    ACCEPTABLE    ', 
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•VALUE   —    USE   MENU1)        (3(A)); 
CALL    MESSAGES; 
CALL    SLCT_VAHJE     (DISPLAY_TBL, DOMAIN_TBL,THE_VALUE, 

'**    SET    VALUE    OPTIONS    **',2); 
SET_VALUE    =    THE_VALUE; 
END; 
END    SET_VALUE_RTN; 

MEM_RTN:       PROC     (MENU_ENTRY  ,SET_MEM)  ; 
/******************************************#***********#*********/ 

/*    This    module    updates    the    SET_MEM    field    in    the   SET  */ 

/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data  base   designer   to   make   a   decision.  */ 

/************** ***************************************** *********/ 

DCL  MENU_ENTRY  CHAR  {6  9)  , 

SET_MEM  CHAR  (2)  , 

THE~VALUE  CHAR  (16), 

I  FIXED    DEC  (2)  ; 

/*         LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE  V 

DISPLAY_TBL  (1)  =  '  1)  MANDATORY    AUTOMATIC;  DOMAIN_TBL  (1 )  =    'MA'; 

DISPLAY_TBL{2)  =  '2)  MANDATORY    MANUAL          ';  DOMAIN_TBL  (  2)  =     'MM'; 

DISPLAY_TBL(3)  =  '3)  OPTIONAL    AUTOMATIC    •;  DOM  AIH_TBL  (3)  =     'OA'; 

DISPLAY_TBL  (4)  =  *4)  OPTIONAL    MANUAL            ';  DOM AIN_TBL  (1)  =    'OM'; 

DISPLAY_TBL  (5)  =  'X)  EXIT  '; 

/*      IF    NO    MENU_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY      */ 

THE_VALUE    =    SET_MEM; 
SET~MEM   =    MENU_ENTRY; 
IF    SET_MEM    =    ■     • 
THEN    DO; 

CALL    SLCT_VALUE     (DISPLAY_TBL, DOMAIN_TBL, THE_VALUE, 
'**    SET    MEMBERSHIP    VALUES    **',U); 

SET_MEM   =    THE_VALUE; 

END; 
ELSE   DO; 

/*      THERE    WAS    A    MENU_ENTEY    —    RETURN    IF    VALID    MENU_ENTRY  */ 

DO    I    =     I    TO    D; 

IF    DOMAIN_TBL(I)     =    SET_MEM 

THEN 

RETURN; 
END; 

/*      THERE    MUST    HAVE    BEEN    AN    INVALID    ENTRY    TO    GET    TO    THIS    POINT. 
WRITE    AN    ERROR    MESSAGE    AND    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY*/ 

PUT    STRING     (HSG)     EDIT     (SET_HEM,'    IS    NOT    AN    ACCEPTABLE    ', 

•VALUE    FOR    SET    MEMBERSHIP    —    USE    MENU')        (3(A)); 
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CALL    MESSAGES; 

CALL   SLCT_VALUE    ( DISPLA Y_TBL , DOMAIN_TBL ,THE_ VALUE, 
■**    SET    MEMBERSHIP~VALUES    **',H); 
SET_H2M    =    THE_VALUE; 
END; 
END    HEM    RTN; 


DUP_OPTION_RTN:       PROC     (MENU_ENTRY,SET_DUP_OPTION)  ; 
/******************* *******************#*********************#**♦/ 

/*   This    module   updates    the    SET_DUP_OPTION    field    in   the    SET  */ 

/*   structure.      If   no   MENU_ENTRY   parameter   is   inputted   into   this  */ 

/*  module,    a   list   of    possible    values    will   be   displayed   for   the  */ 

/*   data   base  desiqner   to  make   a   decision.  */ 

DCL  HENU_ENTRY  CHAR(fc9)  , 

SET_DDP_OPTION  CHAR  (2)  , 

THE~VALUE  CHAR  (16)  , 

I  FIXED    DEC  (2)  ; 

/*         LOAD    DISPLAY    TABLE    AND    DOMAIN    TABLE  */ 

DISPLAY_TBL(I)     = 

•1)        DUPLICATES    FIRST  *;       DOMAIN_TBL  { 1 )     =    'DF'; 

DISPLAY_TBL(2)     = 

•2)        DUPLICATES    LAST  ■;       DOMAIN    TBL(2)     =    "DL1; 

DISPLAY_TBL(3)     = 

'3)  DUPLICATES  NOT  ALLOWED';  DOMAIN_TBL  (3)  =  'DM*; 
DISPLAYJTBL(U)    = 

•X)        EXIT  •; 

/*      IF    NO    MENU_ENTRY    THEN    CALL   ROUTINE   TO    SELECT    A    VALID    ENTRY       */ 

THE_VALUE   =    SET_DUP_OPTION; 
SET_DUP_OPTION    =    MENU_ENTRY; 
IF    SET_DUP_OPTION    =    •     ' 
THEN    DO; 

CALL   SLCT_VALUE    (DISPLA Y_TBL , DO MAIN_TBL ,THE_VALUE, 
'**    SET    DUPLICATE    OPTIONS    **',3); 

SET_DUP_OPTION    =    THE_VALUE; 

END; 
ELSE   DO; 

/*      THERE   WAS    A    MENU_ENTRY    —    RETURN    IF    VALID    MENU_ENTEY  */ 

DO    I   =     1    TO    3; 

IF    DOMAIN_TBL  (I)    =    SET_DUP_OPTION 

THEN 

RETURN; 
END; 

/*   THERE  MUST  HAVE  BEEN  AN  INVALID  ENTRY  TO  GET  TO  THIS  POINT. 
WRITE  AN  ERROR  MESSAGE  AND  CALL  ROUTINE  TO  SELECT  A  VALID  ENTRY  */ 
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PUT    STRING     (MSG)     EDIT     (SET_DUP_0PTION,  ■     IS    NOT    ACCEPTABLE    ', 
•FOE    SET    DUPLICATE    OPTION    —    USE    MENU')         (3(A)); 
CALL    MESSAGES; 

CALL    SLCT_VALUE     (DISPLA Y_TBL ,DO MAIN_TBL,THE_VALUE , 
•**    SET    DUPLICATE    OPTIONS    **',3); 
SET_DUP_OPTION    =    THE_VALUE; 
END; 
END    DUP_OPTION_RTN; 

DRDER_RTN:       PROC     (MENU_ENTRY  ,SET_ORDER)  ; 
/****************************************************************/ 

/*   This    module   updates    the   SET_ORDER   field   in   the   SET  */ 

/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*    data   base   designer   to  make   a   decision.  */ 

^ **************** ************************* ****** *****************/ 

DCL         MENU_ENTRY  CHAR  (69), 

SET_ORDER  CHAR  (5)  , 

THE_VALUE  CHAR  (16)  , 

I  FIXED  DEC(2)  ; 


/* 


LOAD    DISPLAY    TABLE    AND    DOMAIN   TABLE 


*/ 


DISPLAY_TBL(1) 
DISPLAY_TBL(2) 
DISPLAY_TBL(3) 
DISPLAY_TBL(4) 
DISPLAY_TBL(5) 
DISPLAY_TBL(6) 
DISPLAY_TBL(7) 


•1) 

FIRST 

•2) 

LAST 

'3) 

NEXT 

"U 

PRIOR 

*5) 

ASCENDING 

■t) 

DESCENDING 

•X) 

EXIT 

DOMAIN_TBL(1) 
DOMAIN_TBL  (2) 
DOMAIN_TBL(3) 
DOMAIN  TBL(4) 
DOMAINlTBL  (5) 
DOMAIN_TBL(6) 


■FIRST' 
'LAST  ■ 
•NEXT  ' 
'PRIOR' 
'ASC  • 
•DES       ' 


/*       IF    NO    MENU_ENTRY    THEN    CALL    ROUTINE    TO    SELECT    A    VALID    ENTRY 
THE_VALUE   =~SET_ORDER; 
SETloRDER    =    MENU_ENTRY; 
IF    SET_ORDER    =    •     ' 
THEN    DO; 

CALL    SLCT_VALUE     ( DISPLAY_TBL, DOMAIN_TBL ,THE_VALUE, 
i**    set    ORDER    VALUES    **',6)"; 

SET_ORDER   =    THE_VALDE; 

END; 
ELSE  DO; 


*/ 


THERE  WAS  A  MENU  ENTRY  —  RETURN  IF  VALID  MENU  ENTRY 


DO  I  =  1  TO  6; 

IF  DOMAIN_TBL(I) 
THEN 

RETURN; 
END; 


SET  ORDER 


/*   THERE  MUST  HAVE  BEEN  AN  INVALID  ENTRY  TO  GET  TO  THIS  POINT. 
WRITE  AN  ERROR  MESSAGE  AND  CALL  ROUTINE  TO  SELECT  A  VALID  ENTRY  */ 
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PUT    STRING     (MSG)     EDIT     (SET_ORDEF.,  '    IS    NOT    AH    ACCEPTABLE    ', 

'VALUE   FOR    SET    ORDER    —    USE    MENU')        (3(A))  ; 
CALL    MESSAGES; 
CALL    SLCT_VALUE     (DI5PLAY_TBL  ,  DO  MAIN_TBL,THE_  VALUE, 

' **    SET    ORDER    VALUES    **' ,bj ; 
SET_ORDER   =    THE    VALUE; 
END; 
END    ORDER_RTN; 

SORT_LMNT_RTN:       PROC    ( MENU_ENTRY  ,SET_SORT_LMNT)  ; 

/*   This    module    updates    the    SET_SORT_LMNT    field    in   the    SET  */ 

/*  structure.  If  no  MENU_ENTRY  parameter  is  inputted  into  this  */ 
/*  module,  a  list  of  possible  values  will  be  displayed  for  the  */ 
/*   data   base   designer   to   make   a   decision.  */ 

/***** *****************************  ******  ******** *+#  +  ******+ at**/ 

DCL  MENU_NUM  CHAR(3), 

HENU_ENTRY  CHAR  (69)  , 

SET_SORT_LMNT  CHAR  (16), 

(SDB,TBL_SIZE)  FIXED    DEC  (3); 

IF    SET_M  EMBER    =    •     • 
THEN    DO; 

MSG    =    ■    SET    MEMBER    ENTRY    MUST    FIRST    BE    MADE'; 

CALL    MESSAGES; 

RETURN; 

END; 

/*    LOAD    DISPLAY_TBL    AND    DOMAIN_TBL    WITH    DATA    ELEMENTS    OF 
MEMBER    SET*/ 

REC_NAME    =    SET_flEMBER; 

OBTAIN    CALC    RECORD     (RE_CORD)  ; 

CALL    IDMS_STATUS; 

OBTAIN    FIRST    SET    ( POPUL  ATED_WITH)  ; 

IF  ERROR_STATUS  =  '0307' 

THEN    DO;~ 

PUT    STRING     (MSG)     EDIT 

('NO    ELEMENTS    IN    '  ,S  ET_MEMBER,  '    TO    BE    SELECTED    FROM!') 
(3(A))  ; 

CALL    MESSAGES; 

RETURN; 

END; 
DO  TBL_SIZE  =  1  TO  999   WHILE  (ERROR_STATUS  =  OK) ; 

PUT  STRING  (DISPLAY_TBL(TBL_SIZE) )  EDIT 

(TBL_SIZE,')    ',LMNT_NAME)  (X  (2)  ,F(3)  ,2  (A))  ; 

DOMAIN_TBL    =    LMNT_NAME; 

OBTAIN    NEXT    SET     (POPUL ATED_WITH)  ; 
END; 

IF    ERROR_STATUS    -=    '0307' 
THEN    CALL    IDMS_STATUS; 
DISPLAY_TBL(TBL_SIZE    +     1)     =     •       X)        EXIT'; 
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/*IF    NO    SELECTION    THEN    GIVE    LIST    OF    DATA    ELEMENTS    FOE 
MEMBER    RECORD    */ 

IF    MENU_EHTRY    =    •     • 
THEN    DO? 

CALL    GEN_MENO     (MENU_NUM, MENU_ENTRY , 

'**    SELECT   SORT    ELEMENT    **', 
TBL_SIZE,  SLCT_NUM  ,3)  ; 
SET_SORT_LMNT    =    DOMAIN_TBL    (SLCT_NUM)  ; 
RETURN; 
END; 

/*    A    SET_SOBT_LMNT    WAS    GIVEN    —    SEE    IF    IT    IS    ACCEPTABLE  */ 

SET_SORT_LMNT    =    MENU_ENTRY ; 
DO    SUB    =     1    TO    TBL_SIZE; 

IF    SET_SORT_LflNT    =    DOMAIN_TBL  (SUB) 

THEN 

RETURN; 
END; 

/*      A    NON    ACCEPTABLE    SET_SORT_LMNT    WAS    GIVEN.       DISPLAY    ERROR    AND*/ 
/*      GIVE    A    LIST    OF    VALID    CHOICES  */ 

PUT  STRING  (MSG)  EDIT 

(SET_SORT_LMNT, •    NOT    FOUND   IN    '  ,  SET_MEMBER,  '    -    USE    MENU') 

(MA))  ; 

CALL  MESSAGES; 

CALL    GEN_MENU     (MENU_NUM,  MENU_ENTRY  ,  '  **    SELECT    SORT    ELEMENT    **' , 

'    "  TBL_SIZE,SLCT_NUM,3) ; 

SET_SORT_LMNT   =    DOMAIN_TBL  (SLCT_NUM)  ; 
END    SORT_LMNT_RTN; 
END    SET_UPDATE; 
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CHG_DEL_DB:       PP.OC    (DEL_SW)  ; 

/********* ttt******* ************************************»***»****/ 

/*  This  module  displays  the  values  of  the  "current"  DATA_BASE  */ 
/*  occurrence  and  allows  the  data  base  designer  to  chanqe  the  */ 
/*      DATA_BASE    occurrence's   fields    or    delete    the    DATA_BASE  */ 

/*      occurrence's    fields.  */ 

/************************************************** **************/ 

/********************/ 
/*  */ 

/*         CHG_DEL    DB  */ 

/*  */ 

/************♦*******/ 

DCL  MENn_N(JM  CHAR  (3)  , 

MENU_ENTRY  CHAR(fc9), 

SAVE_SAHE  CHAR  (If), 

DEL_SW  CHAR(1)  , 

STATUS  CHAR  (4)  , 

D  CHAR  (6)  , 

DATE  BOILTIN; 

/*    DISPLAY    MENU    AND    MAKE    CHANGES    TO    CURRENT   DATA    BASE    RECORD    */ 

DEL_SW   =    '    • ; 

SAVE_NAME    =    DB_NAME; 

CALL    DB_UP_MENU     (MEN  U_NUM,  MENU_ENTRY, 

■**    CHAMGE    OR    DELETE    DATA    BASE    **• ) ; 
DO    WHILE     (MENU_NUM    -.=    'X'); 
IF    MENU_NUM    =    • 1< 
THEN    DO; 

DB_NAME    =    MENU_ENTRY; 

CALL    EDIT_NAME     (  DB_N  AME,  ST  ATUS)  ; 

IF  STATUS~=  'GOOD' 

THEN  DO; 

IF    SAVE_NAME    =    DB    NAME 
THEN 

ENTER_KEY    =     '     ';  /*    MULL    STATEMENT       */ 

ELSE   DO; 

FIND    CALC    RECORD     (DATA_BASE)  ; 
IF    ERROR_STATUS    -.=    '0326' 
THEN    CALL    IDMS_STATUS; 
IF    ERROR_STATUS    =    REC_FOUND 
THEN    DO;~ 

PUT    STRING     (MSG)     EDIT     (DB_NAME, 

■  ALREADY  EXISTS')   (2(A)); 
CALL  MESSAGES; 
DB_NAME  =  SAVE_NAME; 
END; 
ELSE  DO; 

IF    DB_NAME    -.=    ■     ' 
THEN 

SAVE_NAME    =    DB_NAME;       /*    A    GOOD    DB_NAME    */ 
END; 
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END; 
END; 
ELSE 

DB_NAME   =    '     • ; 
END;" 
ELSE 

DBA    =    HENU_ENTEY; 
CALL    DB_UP_MENU     (MENU_N  UM,  M2NU_ENTRY , 

•**   CHANGE    OH    DELETE    DATA    BASE    ** ■ )  ; 
END; 

/*       IF    BLANK    DB_UAME   THEN    CONFIRM    DELETION    AND    3ITHEB    DELETE    OR 
ABORT    DELETE    REQUEST  */ 

IF    DB_1IAME    =    '     ■ 
THEN    DO; 

CALL    CLRSCR; 

CALL    BLANK_LINE     (5); 

DISPLAY    {'CONFIRM    DELETE    BY    TYPING    "  D"     '); 

CALL  BLANK  LINE  (5)  ; 

DISPLAY     {•====><)     REPLY     (D£L_SW)  ; 

IF    DEL_SW    =     »0« 

THEN    DO; 

PUT  STRING  (KSG)  EDIT  (SAVE  NAME,'  DATA  BASE  DELETED') 
(2(A))  ; 

FIND  CURRENT  RECORD  (DATA_BASE); 

ERASE  RECORD  (DATA_BASE)  ALL; 

CALL    IDMS_STATUS ; 

CALL    MESSAGES; 

RETURN; 

END; 
ELSE    DO; 

MSG    =    'DELETE    REQUEST    ABORTED'; 

CALL  MESSAGES; 

DB_NAHE    =    SAVE_NAME; 

END; 
END; 

/*   MAKE  CHANGES  TO  CURRENT  DATA  BASE  RECORD        */ 

D    =    DATE; 

YEAR_CHANGED    =    SUBSTR  (D,  1  ,  2)  ; 
HONTH_CHAIJGED    =    SUBSTR  (D,  3,2  )  ; 
DAY_CFIANGED    =    SUBSTR  (D, 5,  2)  ; 
MODIFY    RECORD     (DATA_BASE)  ; 
CALL    IDMS_STATUS; 

END    CHG_DEL_DB; 

/**  DB_CUST    module   ends  hero.  **/ 
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**** 
d,  w 
or  ma 
s  us 
2) 
re  la 
sta 
**** 


**** 
ill 
tion 
ed  t 
Val 
tion 
teme 
**** 


***************** 
create  an   opera- 
stored   in    DB_GEN 
o  accomplish   this 
idate   customiza- 
ships,    4)    Create 
nts. 
***************** 


MISSING, 
DATA_CHK 

I     LHNT_  | 

I     DATA_CHK    | 


I    KEC_  | 

1     DATA_CHK    | 

4. «. 

I    SET_  | 

I     DATA_CHK    | 
+ + 


I  I 

I    SIHPLE_       | 
I    «_N  I 


I    SET_  | 

|    COST_CK    | 
+ + 


I 

|        POINTER 
I       CREATE 
I 


DDL_ 
CREATE 


CREATE_SCHEMA:       PROC; 
/**************************** 

/*  This  module,  when  complete 
/*  tional  schema  based  on  inf 
/*  data  base.  Five  sub-system 
/*  are:  1)  Missing  data  check 
/*  tion,  3)  Simplify  complex 
/*  pointer,  and  5)  Create  DDL 
/**************************** 

/* 

/*         CREATE_SCHEHA 

/* 

/*       + +       + 

/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/.* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 
/* 

/* 

/*  t + 

/* 

/♦♦it************************************************* 


ENTIT 
Ct!ST_ 

|    LMN 
I    COS 


|    REC 
I    CUS 


Y_ 
CK 

T_CK     | 

I 

T_CK     | 


|     SCHEMA,    | 
I     DSCR       "    | 

+ + 

+ 1 

I     FILE_         | 
I     DSCR-         | 


|    AREA  | 

I     DSCR  | 

*■ + 

|  RECORD_  | 
I  DSCR  "  | 
+ ___ + 


I    SET_    | 
I     DSCR    | 


***/ 

*/ 
s*/ 

*/ 

V 
*/ 
*/ 

**/ 

*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 

*/ 

*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 
*/ 

***/ 


MSG    =     'CBEATE_SCHEMA    TO    BE    COMPLETED'; 
CALL    MENU_HEAD; 

DISPLAY     ('PRESS    ENTER    TO    CONTINUE')    REPLY     (ENTER_KSY)  ; 
END      CREATE    SCHEMA; 
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PRINT_DATA:       PEOC; 
/♦♦♦a********************* ******#*******#******************#**«»**/ 

/*      This    module    will   print   or   display   information    describing  */ 

/*      a   user's   data    base  schema.  */ 
/*****************************************************************/ 

/*  */ 

/*          PRINT_DATA  */ 

/*  */ 

/*            + +          t +             + +  */ 

/*             |       LMNT_       |           I        LMT               |              |       EECORD_       |  */ 

/*            |        PRINT       |           |        DISPLAY       |              |       PRINT             |  */ 

/*            + +          + +             + +  */ 

/*  */ 

/*            > +       + +       + +       + 1  */ 

/*             |     BECORD_     |        |     SET_       |        |     SET_             I        |     ALL_ENTI  TIES_    |  */ 

/*             J     DISPLAY    1        ]     PRINT    j        |     DISPLAY     I        1             ~PRINT                1  */ 

/*            + +       + +       + +       + +  */ 

/*  */ 

/a****************************************************************/ 

JiSG    =     'PRINT_DATA    TO    BE    COMPLETED'; 

CALL    MENU_HEAD; 

DISPLAY     ('PRESS    ENTER    TO    CONTINUE')     REPLY     (ENTER_KEY); 

END       PRINT_DATA; 
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/**  The    UTILITY_RTNS   start    here  **/ 
/*************#****#**#********#**#**#****#■(,„**##*#***#*****»*****/ 

/*  */ 

/*  t!TILITY_RTNS  */ 

/*  */ 

/*         + «•       + +      + +       + +       t +  */ 

/*  |    GEN_       1        |     SLCT_     |        |     EXAMINE_    |  1     EDIT_    |        |     GEN       |               */ 

/*  I     MENU       ]        |     VALUE    1        |        ENTRY          1  |     NAME       |        |     INST    |               */ 

/*  > «■  «• +         + +         + +         + +  */ 

/*  */ 

/*  ♦ +  «. +  + +         + +         + +  */ 

/*  |     HESSA-    |        |    MENU_    |        |     B1ANK_    |  |     ASRRIC_    |        |     DI V_       |          */ 

/*  J       GES    '     1        |     HEAD       ]        |        LINE       |  1       LINE         J        |     ENTRY     1          */ 

/*  ♦ +       * +       + +       + +       + +  */ 

/*  */ 


DIV_ENTRY:  PROC     (MENU_ENTRY,P  ART_TBL,  STATUS)  ; 

/*******************♦**************♦*#***#***#********$»*********/ 

/*      This    module   is   used   to    divide    a    multiple    MEHU_ENTRY,  */ 

/*      separated   by   semi-colons,    into   parts   and  store  the  */ 

/*      in    the    PART_TBL.  */ 

DCL  MENU_ENTRY  CHAR  (69), 

PART_TBL(20)  CHAR(lfc), 

STATUS  CHAR  (4), 

(START, SUB, I, J)  FIXED(3); 

/********      2EM0VE    ALL   LEADING    ";"  *************/ 

DO    WHILE     (SUBSTR(MENU_ENTRY,1,  1)     =    ■  ;  • )  ; 

DO    I    =     1    TO    fc8       HHILE     (SUBSTR  (M  ENU_ENTRY,  1, 70-1)     -.=    '     *); 
SUBSTR(HENU_ENTHY,I,1)     =    SUBSTR  (HENU_ENTRY,I+ 1  , 1 )  ; 

END; 

SUBSTR  <MENH_ENTRY,  1+1,  1)     =    '     '; 
END; 

/***      REDUCE    ANY    MULTIPLE    CONTIGUOUS    ";"    TO    SINGLE    "; "    ******/ 
DO    I    =    2    TO    68      HHILE    (SUBSTR  (MEN  U_ENTRY, 1, 70-1)     -.=    ■     •); 
DO    HHILE     (SUBSTR(MENU_ENTRY,I,1)  =    ';'  5 

SUBSTR  (MENU_ENTF,Y,  (1+  1)  ,  1)     =    ';'); 
DO   J    =    I    TO    68       WHILE     (SUBSTE  (MENU_ENTB  Y,  J  ,70-J)     -=    •     ')  ; 

SUBSTR(MENU_ENTRY,J,1)     =    SUBSTR  (MEN  U_ENTRY  ,  J  +  l  ,  1 )  ; 
END; 

SUBSTR(MENU_ENTRY,J+1,1)     =    ■     •; 
END; 
END; 

/*****    left    JUSTIFY    ALL    ENTRIES    AGAINST    ";"         *********/ 
DO    I    =    2    TO    £8      WHILE     (SUBSTR  (MENU_ENTRY,  1, 70-1)     -.=    •     •); 

IF    SUBSTR  (MENU_ENTRY, I,  1)     =    •;' 

THEN   DO; 
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DO    WHILE     (SUBSTR(MENU    ENTRY, 1  +  1,1)     =     ■     '); 
DO    J    =     (1+1)     TO    fc8 

WHILE     (SUBSTR(MENU_ENTRY,  1,70-1)     -.=    •     •); 
SUBSTR(MENU_ENTRY,J,1)     =    SUBSTR  (MENU_ENTRY,  J+ 1 ,  1 )  ; 
END; 

SUBSTR(MENU_ENTRY,J+1,1)     =     •     •; 
END; 
END; 
END; 

/***    ONCE    VERIFIED    AS    VALID   LOAD    TABLE    WITH    ENTRIES    ********/ 
START  =    1; 

SUB  =    0; 

PART_TBL    =     '     '  ; 
STATUS        =    'GOOD'; 

DO    I   =    2    TO    68      WHILE     (SUBSTR  (MEN  U_ENTRY, I,  70-1)     -.=     •     '); 
IF    SDBSTR  (MENU_ENTRY,I,  1)     =     •;• 
THEN   DO;  , 

SOB    =    SOB    +    1; 

PARTJTBL(SOB)     =    SOBSTR  (MENU_ENTRY  ,  START  ,I-START)  ; 

/******    sEE    jF    CAND_FIELD    IS     AN    EXISTING    DATA    ELEMENT    ****/ 

LMNT    NAME    =    P  ART_TBL  (SUB)  ; 

SAVeIdB_NAME    =    DB_NAME; 

OBTAIN    CALC    RECORD     (DATA_ELEM  ENT)  ; 

DO   WHILE     (ERROR_STATUS    =    BEC_JOUND); 

OBTAIN    OWMER    SET     (DEFINED_BY)  ;     CALL    IDMS_STATUS; 

IF    SAVE_DB_NAME   =    DB_NAME 

THEN 

ERROH_STATUS    =    'FWND'; 
ELSE 

OBTAIN    DUPLICATE    RECORD     (DATA_ELEMENT)  ; 
END; 

IF     (ERROR_STATUS    -•=    '032fc'     S    ERBOR_STATUS    -i=     'FWND') 
THEN    CALL~IDMS_STATUS; 
IF    ERROR_STATUS    -*=     'FWND* 
THEN    DO; 

PUT    STRING     (MSG)     EDIT 

(•ENTRY    ',SUB,'     DOES    NOT    EXIST    -    USE    MENU1)      (A,F(3),A); 
CALL    MESSAGES; 
STATUS   =    'BAD'  ; 
RETURN; 
END; 
ELSE 

START    =    I    +    1  ; 
END; 
END; 

/**    SEE    IF    THERE    WAS    A    FINAL    ENTRY.        KEYING    ON    » ; "    AND    FINAL    */ 
/**    ENTRY    LIKELY    WILL    NOT    BE   FOLLOWED    BY    A       ";".  */ 

IF    SUBSTB(MENU_ENTRY, START, I-START)     -■=     '     ■ 
THEN    DO; 

SUB    =    SUB+1  ; 

PART_TBL  (SUB)     =    SUBSTR  (MENU_ENTRY,  START  , I-START)  ; 

/********    SEE    IF    CAND_FIELD    IS    AN    EXISTING    DATA    ELEMENT    ****/ 
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LMNT_NAME    =    PART_TBL  (SUB)  ; 
SAVE_DB_NAME    =    DB_NA«E; 
OBTAIN    CALC    RECORD    (  DAT  A_ELEI1EM  T)  ; 
DO    WHILE     (EHROR_STATOS    =    REC_FOUND)  ; 

OBTAIN    OWNER    SET     (DEFINED_BY) ;    CALL   IDMS_STATUS; 

IF    SAVE_DB_NAME    =    DB_NAME 

THEN 

EREOB_STATUS    =    'FWND'; 

ELSE 

OBTAIN    DUPLICATE    RECORD     (DATA    ELEMENT); 
END; 

IF     (ERROR_STATUS    ■*■    ' 032fc*    S    ERROR_STATUS    -.=     'FWND') 
THEN    CALL    IDMS_STATUS; 
IF    ERROR_STATnS    -.=    'FWND' 
THEN    DO; 

PUT    STRING     (MSG)     EDIT 

(■ENTRY     'jSOB,'     DOES    NOT    EXIST    -    USE    MENU1)      (A,F(3),A) 

CALL    MESSAGES; 

STATUS    =    'BAD' ; 

RETURN; 

END; 
END; 
EFD    DIV_ENTRY; 


GEN 

_MENU: 

/********** 

/* 

This  mo 

/* 

varible 

/* 

identif 

/* 

selecti 

/* 

The  con 

/* 

in  1,  2 

/* 

NUM  COL 

/********** 

PROC     (MENU_NUM,MENU_ENTRY,MENU_HSG,TBL_SIZE, 
SLCT_NUM,NUM_COLS)  ; 
******************************************************/ 

dule   displays   a   menu  that    is    provided   in   the   global  */ 

,    DISPLAY_TBL.       The   size    of   the   DISPLAY_TBL   is  */ 

ied   by   the   TBL_SIZE   parameter.      The  user    makes   a  */ 

on    that    is    divided    into   MENU_NUM    and   MENU_ENTRY.  */ 

tents   of    DISPLAY_TBL  is   displayed   on   the   screen  */ 

,   or   3   columns    depending    on   the   value   of   the  */ 

S   parameter.  */ 
*********  ***************************** ****************/ 


DCL  MENU_NUM  CHAR  (3), 

MENU_ENTRY  CHAR  (69)  , 

SLCT  CHAR  (72), 

MENU_MSG  CHAR  (10)  , 

(TBL_SIZE,NUM    SCREENS)  FIXED    DEC  (3)  , 
(SLCT_NUM,I,j7NUM_CHOICES)        FIXED    DEC(3), 

SLCT_STATUS  CHAP.  («)  , 

NUM_COLS  FIXED    DEC(1); 


/* 


DISPLAY  MENU   /   ACCEPT  REPLY 


SLCT  =  ■  • ; 

IF  NUM_COLS  =  1 
THEN 

NUM_CHOICES  =  15; 
ELSE  IF  NUM_COLS  =  2  THEN 

NUM_CHOICES  =  30; 
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ELSE    IF    NUM_COLS    =    3    THEN 

NUM_CHOICES    =    45; 
ELSE 

DISPLAY     ("PROGRAMMER    ERROR    IN    GEN_MENU    •) 
REPLY     (ENTER_KEY); 


^CHOICES    -    1)  )    =0 
_SIZE/(NUM_CHOICES 


IF    HOD  (TBL_SIZE,(NUM_ 
THEN 

NOM_SCREENS    =    {TBL_SIZE/  (N 0B_CH DICES   -    1))     -    1; 
ELSE 

NUM_SCREENS    =    (TBL_SIZE/ (NUM    CHOICES    -    1)); 
SLCT_STATUS    =     'BAD'; 
DO    WHILE     (SLCT_STATUS    =    'BAD'): 

DO    I    =    0    TO    NUM_SCREENS       SHILE     (SLCT    =     '     ')  ; 
MSG    =    MENU    MSG; 
CALL    MENU_HEAD; 
DO   J    =    1    TO    15; 

IF    N0M_COLS    =     1    THEN 

PUT    STRING     (EDIT_OOT)     EDIT 

(DISPLAY_TBL(J+  (I*  NUM_CHOICES)  )  )      (A)  ; 
ELSE   IF    NUM_COLS    =    2    THEN 
PUT    STRING     (EDIT_OUT)     EDIT 

(DISPLAY_TBL  (J+  (I*  NUM_CHOICES)  )  , 

DISPLAY_TBL  (J    ♦    1  5    +     (I*NUM_CHOICES)  )  ) 
(A  (48),  A  (24))  ; 
ELSE    IF    NUM_COLS    =    3    THEN 
PUT    STRING    (EDIT_OUT)     EDIT 

(DISPLAY_TBL  (J+  (I*  NUM_CHOICES)  )  , 


DISPLAY_TBL(J 
DISPLAY    TBL  (J 
(3(A(2H)))  ; 
DISPLAY     (EDIT_OUT)  ; 
END; 

CALL  BLANK_LINE(1)  ; 
IF  I  <  NUM_SCREENS 
THEN 


15 
30 


(I*NUM. 
(I*NUM. 


CHOICES)  )  , 
CHOICES)  )  ) 


/*  I.E.   MORE  DATA    */ 


DISPLAY 


(•MAKE 
REPLY 


SELECTION 
(SLCT)  ; 


OH  PRESS  ENTER  ===>■) 


ELSE 

DISPLAY     ('MAKE    SELECTION    ===>')        REPLY     (SLCT) 
END; 
CALL    EXAMINE    ENTRY 


END    GEN 


END; 
MENU; 


(SLCT,MEMU_NUM,MENU_EMTSY,SLCT_NUM, 
SLCT_STATUS,TBL_SIZE)  ; 


SLCT_VALOE:       PEOC    (DISPLAY_TBL,DOMAIN_TBL, 

THE_VALUE,MENU_MSG,TBL_SIZE) ; 
/ft**************************************** ** ******* *************»/ 

/*  This  module  displays  a  menu  that  is  provided  in  the  DISPLAY_  */ 
/*  TBL.  The  user  enters  a  number  representing  a  menu  selection  */ 
/*    and   the   value   of   that   selection   is   moved   to   the  output  */ 

/*   parameter,    THE_VALUE.  */ 

/***********^**  *********************************************  ****<,/ 


177 


DCL  DISPLAY_TBL(500)  CHAE  (72)  , 

DOBAIN_TBL(500)  CHAR(lfc), 

THE_VALUE  CHAH(16), 

MENU_MSG  CHAE (30), 

SLCT  CHAE  (7 2), 

(TBL_SIZE,I,SLCT_NUtt)  FIXED    DEC(3), 

STATUS  CHAE  (4), 

MENU_NUM  CHAE(3), 

MENU_ENTRY  CHAR(69)  ; 

STATUS  =  'BAD'; 

DO  WHILE  (STATUS  =  'BAD'); 

NSG  =  MENU_HSG; 

CALL  MENU_HEAD; 

DO  I  =  1  TO  TBL_SI2E; 

DISPLAY  (DISPLAY_TBL(I)  )  ; 

END; 

DISPLAY     (DISPLAY    TBL(I)); 

CALL    BLANK_LINE(2)  ; 

DISPLAY    ('====>*)        EEPLY    (SLCT)  ; 

CALL   EXAMINE_ENTRY    (SLCT, HENU_NUM, MENU    ENTRY, SLCT_HUH, 
STATUS, TBL_SIZE) ; 
END; 

IF    MENU_NUM    -.=    'X' 
THEN 

THE_VALUE    =    DOMAINJTBL  (SLCT_NU?l)  ; 
END    SLCT_VALUE; 

EXAMINE_ENTRY:       PEOC     (SLCT, M  EN0_NUM,  MENU_ENTRY  , SLCT    NUM, 

SLCT_STATUS,UP_LIMIT)  ; 
/ft********************  *************#  s********************^*^,,,,,,^ 

/*  This  module  examines  an  entry  made  by  the  data  base  designer.*/ 
/*  The  SLCT  parameter  contains  the  value  inputted  by  the  data  */ 
/*  base  desiqner  which  is  divided  into  MENU_NUH  and  HENU_ENTRY.  */ 
/*  SLCT_NUfl  is  the  numeric  equivalent  to  the  I1ENU_NUM  which  is  */ 
/*   of   type  character.  */ 

DCL  SLCT  CHAR  (72)  , 

MENU_ENTRY  CHAR(69), 

HENU_NTJM  CHAR  (3), 

(UP_LIHIT,SLCT_NU«,I,J)  FIXED    DEC(3)  , 

SLCT_STATUS  CHAR  (4)  ; 

/*         CHECK    FOB    NULL    ENTRY    BY    USEE  */ 

IF    SLCT    =    •     • 
THEN    DO; 

CALL    GEN_IHST; 

SLCT_STATUS=     'BAD' ; 

RETURN; 

END; 
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/*         LEFT    JUSTIFY    SLCT   —    USEE    MIGHT    SPACE    BEFOEE    ENTRY         */ 

DO    WHILE     (SUBSTR  (SLCT,  1,  1)    =     '     '); 
DO   I   =    1   TO    71; 

SUBSTR(SLCT,I,1|     =    SUBST  B  (SLCT  ,1  +  1  ,  1 )  ; 
SUBSTR  (SLCT,  1+1,  1)    =     •     '; 
END; 
END; 

/*         CHECK    FOR    EXIT    BEQUEST  */ 

IF    SUBSTR  (SLCT,  1,  1)     =    'X' 
THEN    DO; 

MENU_NUM   =    'X'; 

SLCT~STATUS    =    'GOOD'; 

RETuIn; 

END; 

/*         ROTATE    RIGHT    ALL    CHARACTERS    OUT    OF    FIRST    3    POSTITIONS    THAT 
ABE    NOT    '     '    OR    NUMERIC   —    SET    UP    MENU_NUM  */ 

DO    J   =     1    TO    3; 

IF    (SUBSTR  (SLCT,  J,  1)     -■='•£ 
i  (SUBSTR  (SLCT,  J,  1)     >=     '0'       S 
SUBSTR  (SLCT,  J,  1)       <=     '9')) 
THEN    DO; 

DO    I    =    72    TO    (J+1)     BY    -1  ; 

SUBSTR  (SLCT, I,  1)     =    SUBST  R  (SLCT, I-  1  ,  1)  ; 
SUBSTR  (SLCT, I- 1,1)     =    •     •; 
END; 
END; 
END; 

/*  DIVIDE    SLCT    INTO    MENU_NUM    AND    MENU_ENTRY  */ 

GET    STRING    (SLCT)     EDIT    (MENU_NUM  ,ME1IU_ENTE  Y)      (A  (3)  ,  A  (69)  )  ; 

/*         LEFT    JUSTIFY    MENU_ENTRY  */ 

IF    MENU_ENTRY    -.=    ■     ■ 
THEN    DO; 

DO    HHILE     (SUBSTR  (MENU_ENTRY,  1,  1)     =     •     '); 
DO    I    =    1    TO    £8; 

SUBSTE(MENU_ENTEY,I,1)     =    SUBSTE  (  MENU_ENTRY  ,1  + 1  , 1 )  ; 
SUBSTE(MENU_ENTRY,I+1,  1)     =     •     '; 
END; 
END; 
END; 

/*       EMBEDDED    BLANKS    —    MAKE    POSITION    3    OF    MEUU_NUM    PART    OF 

MENU_ENTEY  */ 

IF    SUBSTR  (MENU_NUM,  3,1)     -.=    '     ' 
THEN   DO; 
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DO   J   =    69    TO    2    BY    -1 ; 

SUBSTR(MENU_Et.'TRY,J,  1)    =    SUBSTR(MENU    EIWBf,  (iJ-  t»  ,  tl J 

END; 

SUBSTR  (MENU_ENTRY,  1,1)     =    S  UBST  R  (MENU_NUM,  3,  1)  ; 

SUBSTR  (MENU_NUH, 3,  1)    =     '     •; 

END; 

/*         CONVERT    CHARACTER     (MENU_NUM)     TO    NUMBER     (SLCT_NUH)  */ 

GET    STRING     (MENU_NUM)     EDIT     (SLCT_NUM)      (F  (3)  )  ; 

/*         CHECK    UPPER    5    LOWER    LIMITS.       NOTE:       ALL    BLANKS    HOULD 

CONVERT   TO    ZERO    AND    WOULD   THEREFORE    BE    INVALID.  */ 

IF    (SLCT_N1JH    >    0       £    SLCT_NUM    <=    UP_LIMIT) 
THEN 

SLCT_STATUS    =    'GOOD'; 
ELSE   DO; 

SLCT    =     •     ';  /*       NECESSARY    TO    REDISPLAY    SELECTIONS    */ 

MSG    ■    'HOT    A    VALID    MENU    NUMBER     •; 

CALL  MESSAGES; 

SLCT_STATUS    =    'BAD'; 

END; 
END    EXAMINE_ENTRY; 

EDIT_NAME:  PROC    (NAME,    STATUS) ; 

/********»******* *************»******#******##*»***#*#*#***»»**»*/ 
/*  This  module  receives  NAME  as  input  and  attempts  to  make  it  */ 
/*  a  compilable  field  name.  If  the  name  cannot  be  made  valid,  */ 
/*   then    the   output    parameter,    STATUS,    is    set    to    "BAD".  */ 

DCL         NAME  CHAR  (16)  ,     ' 

STATUS  CHAR  («)  , 

(END_POS,I,J)  FIXED    DEC  (3); 

STATUS   =    'GOOD'; 

IF    NAME    =    '     • 
THEN 

RETURN; 

/*      LEFT    JUSTIFY    NAME  */ 

DO  WHILE  (SUBSTR(NAME,1,  1)  =  '  '); 
DO  I  =  1  TO  15; 

SUBSTR(NAME,I,1)  =  SUBSTR  (NAME  ,1+ 1  ,  1 )  ; 
SUBSTR(NAME,I  +  1,1)  =  '  '; 
END; 
END; 

/*   LOCATE  ENDING  POSITION  OF  NAME.  */ 
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END_POS   =    16; 

DO    I   =    16    TO    1     BY    -1       WHILE     (SUBSTR  {NAME, 1 ,  1)     =     •     ')  ; 

END_POS   =   1-1 ; 
END; 

/*   VEEIFT  1ST  CHARACTER  AS  ALPABETIC  */ 

IF  (SUBSTR(NAME,1,1)  <  'A'  |  SUBSTR  (NAME,  1  ,  1)  >  'Z') 
THEN  DO; 

MSG  =  'FIRST  POSITION  OF  DATA  BASE  NAME  NOT  ALPABETIC; 

CALL  MESSAGES; 

PUT  STRING  (MSG)  EDIT 

('YOUR  ENTRY  WAS  ==>  '.NAME)   (2(A)); 

DISPLAY  (MSG) ; 

STATUS  =  'BAD'; 

RETURN; 
END; 

/*   REDUCE  IMBEDDED  BLANKS  TO  DASHES    */ 

1=2; 

DO  WHILE  (I  <  END_POS)  ; 

IF  (SUBSTR  (NAME, I,  1)  =  ■  '  |  SUBSTR  (NAME,  I,  1)  =  •-'  | 

SUBSTR  (NAME, I,  1)  =  •_•  ) 
THEN  DO; 

SUBSTR(NAME,I,1)     =     '-•; 
IF     (SUBSTR  (NAME, 1+1,1)     =     '     '     I 
SUBSTR  (NAME, 1+1,  1)     =    •-•     | 
SUBSTR  (NAME, 1+1,  1)    =     '_•) 
THEN    DO; 

DO    J    =    1+1    TO    END_POS    -    1; 

SUBSTR  (NAME,  J,  1)~    =    SUBSTR  (NAME,  J+ 1 ,  1)  ; 
SUBSTR  (NAME, J+1,  1)     =    ■     •; 
END; 

END_POS    =    END_POS    -     1; 
END; 
ELSE 

1=1+    1; 
END; 
ELSE 

1=1+1; 
END; 

/*       VERIFY   POSITIONS    2    THROUGH    END_POS    AS    A    DASU,     NUMBER,    OR 

LETTER  */ 

DO    I   =    2    TO    END_POS; 

IF  i  (SUBSTR(NAME,I,  1)  =  '-■  | 
(SUBSTR  (NAME, I,  1)  >=  'A'  8 
SUBSTR  (NAME, I,  1)  <=  '9')) 
THEN  DO; 

PUT  STRING  (MSG)  EDIT  ('ERROR  ~  INVALID  ', 
'CHARACTER  IN  POSITION ',  I,  '  OF  ',NAXE)   (2(A), 
F(2),2(A)); 
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CALL    MESSAGES; 
STATUS   =    ' BAD' ; 
RETURN; 
END; 
END; 
END    EDIT_NAHE; 

GEN_INST:   PROC; 

/#*************** ************************************************/ 

/*  This  module  displays  the  qeneral  instructions  for  inter-     */ 

/*   actinq  with  DB_GEN.  ♦/ 

/***********************************  t**************!,*************/ 

/* 

SOME  GENERAL  USER  INSTRUCTIONS  FOE  USING  THIS  PROGRAM 

*/ 
CALL  CLRSCR; 

DISPLAY     (•  **    GENERAL    INSTRUCTIONS'); 

CALL    BLANK_LINE  (2)  ; 

DISPLAY     (•    TWO    FORMATS    CAN    BE    USED    — ')  ; 

DISPLAY     ('     •)  ; 

DISPLAY     {•     FORMAT    1:  <MSNU_NUM>' )  ; 

DISPLAY     (•     ')  ; 

DISPLAY 

(*==>    THIS    WILL    PROVIDE    DETAILED    INSTRUCTIONS    FOR    ENTERING'); 

.   DISPLAY     (•  THE    RESPECTIVE    INFORMATION')  ; 

DISPLAY     (•     •)  ; 

DISPLAY     (•    FORMAT    2:  <MENU_MUN>    <MENU_ENTRY>  •)  ; 

DISPLAY    ('     •)  ; 

DISPLAY 

(•==>  THE    DETAIL    INSTRUCTION    STEP    IS    SKIPPED    BY    ADDING    THE    ■); 

DISPLAY     (•  MENU    ENTRY         E.G.        1       PART_NUMBES    '); 

CALL    BLANK_LINE  (2)  ; 

DISPLAY     ('PRESS    ENTER    TO    CONTINUE')     REPLY    (ENTER    KEY); 

END    GEN_INST; 

MESSAGES:       PROC; 

/*********************************************  *****ifififififiilfJfif+iftJr*/ 
/*     This   module   writes    a   messaqe   to   the   screen.      It   displays  */ 

/*      the   value   of    the  qlobal   varible,    MSG,    and   waits   for    the    user*/ 
/*      to   respond   before   continuinq.  */ 

/****************  ***********************************  ****m*tttt:l,tJI,/ 

CALL    CLRSCR; 

CALL    BLANK_LINE(3)  ; 

CALL    ASTRICK_LINE  (2)  ; 

CALL    BLANK_LINE(1)  ; 

DISPLAY     (MSG); 

CALL    BLANK_LINE(1)  ; 

CALL    ASTRICK_LINE  (2)  ; 

CALL    BLAHK_LINE(3)  ; 

DISPLAY    ('PRESS    ENTER    TO    CONTINUE')     REPLY     (ENTER    K2Y)  ; 

END    MESSAGES; 

MENU_HEAD:       PROC; 
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/♦a**************************************************************/ 
/*  This  module  clears  the  screen  and  prints  the  "current"  data  */ 
/*  base  name  in  the  upper  right  hand  corner  of  the  screen.  */ 
/****************************************************************/ 

CALL   CLRSCB; 

OBTftIN    CALC    RECORD     (tATA_BASE); 

IF    ERROR_STATUS    =    '0326' 

THEN 

DB_NAME   =    '????• ; 
ELSE 

CALL    IDMS_STATUS; 
PUT    STRING     (EDIT_OUT)     EDIT     ("DATA-BASE:        '  ,  DB    NAME) 

(X(40)  ,A,A); 
DISPLAY     (EDIT_OUT)  ; 
CALL    BLANK_LINE  (1)  ; 

PUT    STRING     (EDIT_CUJT)     EDIT     (MSG)      (X{10),A); 
DISPLAY     (EDIT_OUT)  ; 
CALL    BLANK_LINE(1)  ; 
END    MEND_HEAD; 

BLANK_LINE:       PROC  (NUM_LINE)  ; 
/****************************************************************/ 

/*  This  module  prints  a  blank  line  -  used  for  screen  formatting.*/ 
/****************************************************************/ 

DCL        (NDM_LINE,I,J)  FIXED    DEC(3); 

DO    I    =    1    TO    NDM_LINE; 

DISPLAY     ('     ')  ; 
END; 
END    BLANK_LINE; 

ASTRICK_LINE:       PROC ( NDM_LINE) ; 
/****************************************************************/ 

/*   This    module   prints  an  astrick   line   -   used   for   screen  */ 

/*   formatting.  */ 

/♦it*************************************************************/ 

DCL        (NUM_LINE,I,J)  FIXED    DEC{3)  ; 

DO    I    =     1    TO    NUM_LINE; 

DISPLAY     (•********** *********************************** ******  )  ; 

END; 

END    ASTEICK_LINE; 

MSG    =     'NORMAL    PROGRAM    TERMINATION'; 

CALL    MESSAGES; 

END    DB_GEN; 
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ABSTRACT 

This  thesis  describes  the  automation  of  the  data  base  de- 
sign process  by  using  the  principles  of  schema  normaliza- 
tion, the  data  dictionary  concept,  and  a  sound  data  base  de- 
sign methodology.  The  implementation  of  this  data  base 
desiqn  tool  aids  the  data  base  designer  in  the  monumental 
task  of  designing  the  user's  data  base  schema. 

This  implementation  uses  an  interactive  menu  driven  sys- 
tem to  aid  the  data  base  administrator  throughout  the  entire 
data  base  design  process.  The  initial  step  collects  only 
necessary  data  (i.e.,  functional  and  nonfunctional  dependen- 
cies) to  generate  the  major  data  base  entities.  Once  the 
major  entities  are  generated  the  data  base  administrator  is 
able  to  interactively  customize  the  entities  to  best  de- 
scribe the  users'  needs.  Finally  the  actual  data  base  man- 
agement system  data  definition  statements  representing  the 
users'  data  base  are  generated. 

This  paper  describes  an  implementation  of  this  process 
using  the  PL/I  Optimizing  Compiler  supported  by  the  IDKS 
version  5.7  generalized  data  base  management  system.  The 
system  operates  under  IBM's  CP/CMS  operating  system. 


